[Distutils] library development patterns

Nick Coghlan ncoghlan at gmail.com
Tue Jan 16 22:01:28 EST 2018


On 17 January 2018 at 06:33, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2018-01-16 19:13:31 +0000 (+0000), Brett Cannon wrote:
>> 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).
> [...]
>
> At least with tox you get this more or less automagically (I know
> plenty of people aren't tox fans, but it still merits pointing out).
> For those unfamiliar, it has implicit environments defined for minor
> (in the SemVer sense) Python versions so your project can define a
> list of which versions it's intended to support and then anyone
> running it by default gets tests executed under each of those for
> which they have a viable interpreter on their path.

The tox model is the one we decided to natively support in Fedora as
well - while there's only ever one "full" Python 3 stack in the main
repos (with all the distro API bindings, etc), there are also
interpreter-only packages for other still supported and/or still
popular Python X.Y branches, and "dnf install tox" will bring in all
of them as weak dependencies.

Hence my preference for where I think it would make sense to take
pipenv in this regard: better *enable* the tox model, without
*duplicating* the tox model.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Distutils-SIG mailing list