On 16 January 2018 at 05:46, Brett Cannon <br...@python.org> wrote: > On Mon, 15 Jan 2018 at 00:33 Chris Withers <ch...@withers.org> wrote: >> >> Hi All, >> >> Couldn't find an obviously better discussion forum than this for pipenv >> stuff, but please point me to where the rest of the discussions are >> happening... > > > Not here from what I can tell. :) Probably your best bet is to ask on the > pipenv GitHub project and file an issue so the pipenv docs can give you > guidance. I know for me personally it's getting a bit hazy between this list > and pypa-dev where stuff should go (I'm personally starting to shift towards > pypa-dev and considering this actually for distutils proper).
Personally, I don't think mailing lists in general are a great medium for asking usage and support questions. 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 >> 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? > > Beats me. I think there's a command to get back to the venv that pipenv > created on your behalf. "pipenv --venv" gives the path for the current project, so what I tend to do is run "ls -s $(pipenv --venv) .venv" from the directory containing Pipfile and Pipfile.lock in order to create a deterministic path name. >> 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). > > That doesn't fall under pipenv's purview. Think of pipenv as trying to make > venv + pip easier to work with. Since you don't use pip to express > dependencies for your library then you shouldn't with pipenv either. Or put > another way, think of your pipfile as just a different format for a > requirements.txt file, not a replacement for flit or setuptools. 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/) 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 All the testing and linting dependencies then go under [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), the best current approach is to use "pipenv lock --requirements" to export just the library dependencies from Pipfile.lock. That's an area that could definitely use some UX improvement, but it isn't clear to me at this point what that would actually look like (short of adding a notion of named "install profiles" to the lock file format, which could then be aligned with tox test environments). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
