On Tue, 16 Jan 2018 at 11:00 Chris Withers <ch...@withers.org> wrote:
> Okay, so lets be up front: pipenv is not for libraries or reusable apps, > it's for deployments of re-usable apps or development of single-use > application code. I think that's a great aim and covers *all* the end > use cases of Python at its extreme. > > However, library devs, and I'd lump reusable app devs in that too... > > On 16/01/2018 17:36, Brett Cannon wrote: > > > > Is there a library developer workflow that's being promoted then > > somewhere that I'm just not finding? Or does that need to be written for > > packaging.python.org <http://packaging.python.org> (which I /might/ be > > willing to write; see below for motivation)? > > Well, I can only speak from my experience as a maintainer of lots of > small libraries that are occasionally heavily used... > > What's worked well for me is specifying dependency ranges in setup.py > and using 'build' and 'test' extras to indicate libraries that are > needed to build artifacts for readthedocs or pypi, the latter for > running automated tests. > This works if you use setuptools, but e.g. flit doesn't support extras dependencies so this isn't a general solution yet. > > I generally use pip install -e . in a checkout to set up a development > environment but beyond this I think things branch out a lot: > > How do you do axis development? (often python version, but can be a > major version of a dependency such as django, or operating system, or > for the lucky masochists out there: a dot product of each of those...) > > For me, I use travis-ci coupled with a few local virtualenvs for canary > versions. Some people like tox here, I never got on with it. > This is part of what I would want us to come to a consensus on. For example, do people just create a venv per Python version they want to test/support, do they use pew or some other tool I don't know about? For VS Code we need to know how to detect what Python interpreters you might want to use with your workspace/folder so we know what interpreters to present to you to select from (and you *have *to select one for when you do things like want to execute a file or run tests). > > Then it's "what testrunner do you use?", I'm gradually moving to pytest, > but I still have a lot of nose 1. > > As far as build and deployment, again, travis's tag-based deployment > model that pushes artifacts to pypi, coupled with readthedocs > pull-and-publish works for the things I care about. Then I guess you > could talk about issue trackers and, indeed, community discussion > channels ;-) > > > I wonder how much of this makes sense to put in a how-to for library > developers and where it branches out into areas where there are multiple > legitimate choices? > I would assume scoping of what is discussed for packaging.python.org would be scoped to what https://packaging.python.org/tutorials/managing-dependencies/ covers, which is just stuff related to dependency management. What test runner to use, etc. seems out-of-scope for there and starts to fall into blog posts and such (e.g. if TIP wants to start a testing.python.org and have tutorials there they probably could, but otherwise there is no official testing location like there is for packaging).
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig