Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[MRG/REVIEW] Support Pipfile / Pipfile.lock with pipenv #649
To help you review this PR
I've added a new buildpack, it will allow repo2docker to detect Pipfile / Pipfile.lock and use them to install Python packages with
There are 48 files changed in this PR, but most of them are relating to tests of the functionality added. Other than these tests, we have changes to...
.gitignore - When running tests locally I ended up with some artifacts, this change helped me avoid these.
The rest of the files are for the tests within the
The strategy adopted was to mimic sections for how a
What to review
Why didn't I use PyEnv?
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:
As setup.py can be explicitly installed or not from a Pipfile I reasoned that it should not be installed by default after pipenv has used relevant Pipfiles.
We want to use the more specific version, Pipfile.lock, if it is available. Are we ignoring the Pipfile if it is, as we should?
Apparently testing to import the package will work no matter what as we will find it locally so setup.py may not need to run. By adding a small dependency I could check if the dependency is installed and now the tests actually tests what they should.
This is the actual meat while most previous commits were tests to verify that this worked as intented. The tests paid off quickly as this was quite hard to get working at all. - We can not use `pipenv shell` inside this script. - We must use `--system` and therefore `pipenv install` that supports it rather than `pipenv sync` that doesn. - We must generate a `Pipfile.lock` if there are none. - We must use `--ignore-pipfile` and `--deploy` on the `pipenv install` command in order to mimic how a `pipenv sync` would have worked.
The '//' will render to '/' in the Dockerfile that allows the RUN command to continue on a new line. I initially added a '//' within a python string on a blank line in order to format things within the Python file to look potentially nicer, but this is of little importance and I have now removed it again.