[Distutils] library development patterns

[Brett Cannon]

On Tue, 16 Jan 2018 at 11:00 Chris Withers <chris at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180116/c722c73e/attachment.html>