On 16/01/2018 04:24, Nick Coghlan wrote:
Anyway, we genuinely don't have a clear answer to this question, so
I've posted a meta-issue on the pipenv tracker to decide how we want
to handle it: https://github.com/pypa/pipenv/issues/1305
Thanks!
Continuing on the deployment theme: I'm used to being able to put
/path/to/some/ve/bin/some_script in crontabs and the like, where
some_script comes form a setuptools entry point.
What's the canonical way of doing this with pipenv?
"pipenv --venv" gives the path for the current project, so what I tend
to do is run "ln -s $(pipenv --venv) .venv" from the directory
containing Pipfile and Pipfile.lock in order to create a deterministic
path name.
Hmm, that feels hacky. It doesn't feel like there's consensus on this
issue, and there's enough dupes coming in that it feels a shame that
https://github.com/pypa/pipenv/issues/1049 has been closed.
I actually want both use cases in different scenarios. For dev, I
typically want one venv per python version (how do I do that?) somewhere
central. For deployment, I want a ./.venv or ./ve right next to the Pipfile.
Last up, how should pipenv be used for library development? (ie: where
dependencies and minimal constraints are expressed in setup.py and where
you want to test against as many python versions and library
combinations as you support).
pipenv does cover this case to some degree - the trick is that it
involves thinking of your library's *test suite* as the application
you want to deploy. (Hence the reference to "development and testing
environments" at the end of the intro to
https://packaging.python.org/tutorials/managing-dependencies/)
As an aside: I find the doc split difficult. Even as a relatively
experience python dev, knowing that I wanted to figure out what pipenv
does and how to use it, I started at
http://pipenv.readthedocs.io/en/latest/ which has no links to the
tutorial(s).
For that case, you don't put *any* of your dependencies from
`setup.py` into `Pipfile`, you just run "pipenv install -e src", which
will give you a Pipfile entry like:
"<commit-hash>" = {editable = true, path = "src"}
I personally then edit that entry to replace the commit hash with the
actual project name
I'm afraid I don't know enough about pipenv internals to understand the
implications of the above, or why you might want to change the commit
has to the project name, and indeed, what the implications of that might be.
All the testing and linting dependencies then go under [dev-packages].
Where can I find out more about [dev-packages]?
The part you can't fully rely on yet is the lock file, since that aims
to lock down the version of Python as well, not just the versions of
the Python level dependencies. So if you're testing across multiple
versions (e.g. with tox),
...or a .travis.yml axis for CI, or just separate venvs for local dev,
in my case...
the best current approach is to use "pipenv
lock --requirements" to export just the library dependencies from
Pipfile.lock.
...but what do I do with Pipfile.lock then? .gitigore?
cheers,
Chris
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
