On 17 January 2018 at 05:21, Brett Cannon <br...@python.org> wrote: > Well, technically we need consensus so we agree that what goes up on > packaging.python.org makes sense; I'm not worried about the whole world. :) > I mean I'm not even after specifically recommended testing practices and > such since that seems outside the realm of packaging.python.org. I'm more > interested in e.g. how should people handle venvs when they support more > than one version of Python? Documenting not pinning your dependency > versions. How do you specify what is required for testing and such so that > you can generically know how to get those dependencies installed in your > venv if you don't want to have your eventual wheel to include those > test-only dependencies? Basically I'm after a tutorial on how to handle > packaging while developing a library. I view "use tox, use pytest" as > something under TIP's purview to create a tutorial/guide for.
Right, one of the things we worked out when Jon wrote the pipenv-based application dependency management guide was that "Install this library to my user directory so that I, the human Nick Coghlan, can use it in my personal scripts" is a different task from declaring application dependencies, and the subsequent feedback we've received (including this thread) shows that library/framework dependency management is slightly different again (and dependency management for portable applications that work across multiple Python versions will look more like the latter than the former). I think tox provides a good precedent for what's needed when it comes to effectively targeting multiple environments: you want a venv per target environment per project, not just a venv per project. However, while that's a configuration I'd personally like to see us better *enable* in pipenv, I wouldn't want it to come at the expense of the core notion of a "preferred deployment environment" as represented by Pipfile.lock, and I'd also prefer that it didn't come at the expense of making the lock file format itself more complex. One way we could do that is to add a "--lockfile" option to both "pipenv lock" and the "pipenv sync" subcommand proposed in https://github.com/pypa/pipenv/issues/1255, and a "--venv" option to the latter, such that the workflow for libraries/frameworks/portable applications would be: * use Pipfile/Pipfile.lock as normal for your "recommended development environment" (e.g. the most recent supported Python version for access to the most up to date developer tools, or perhaps the oldest supported Python version to minimise the risk of breaking compatibility). The "interactive" pipenv subcommands (install, uninstall, update, run, shell) would all continue to work specifically on the default lock file and venv. * use "pipenv lock --python TARGET --lockfile PATH_TO_TARGET_LOCKFILE" to generate target specific lockfiles for other environments * use "pipenv sync --lockfile PATH_TO_TARGET_LOCKFILE --venv PATH_TO_TARGET_VENV" to configure virtual environments based on those alternate lock files Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
