[TIP] Why does tox use "pip install --pre" by default?

Marius Gedminas marius at gedmin.as
Mon Sep 29 22:50:40 PDT 2014


On Mon, Sep 29, 2014 at 06:32:49PM +0000, holger krekel wrote:
> "consistency with pip" is a valid point in principle.
> 
> However, does anybody argue that "pip install --pre" was itself a good idea? 
> 
> Are there many examples (besides Ned's) of people relying and using 
> that feature?
> 
> I doubt it because:
> 
> - you can't really depend on "--pre" because "easy_install" does not
>   support it and it's still producing some 20-25% of install actions
>   (https://caremad.io/blog/a-look-at-pypi-downloads/ )

Reminder that zc.buildout shows up as easy_install.

zc.buildout has an option `prefer-final`, which is the opposite of pip's
--pre.

zc.buildout 2.0 made a backwards-incompatible change and defaulted to
`prefer-final` being true back in 2013.


I've had intense debugging and head-scratching sessions where I couldn't
reproduce test failures I've seen with buildout with tox and vice-versa,
which I eventually tracked down to the difference in preferring final
package versions.  (It was a good thing, in retrospect -- the package
under test should've work with both sets of packages, or should've
specified version restrictions in its setup.py.)

> > I am not in a good position to evaluate the likely back-compat effects,
> > since I don't ever use tox in a way that relies on --pre (if I want to
> > test against a pre-release version of a dependency, I specify the
> > precise pre-release I want to test against).
> 
> I don't know how many people would really be hit by tox changing its
> defaults.  For sure, if a tox.ini specifies "easy_install" you could not
> run "tox --pre" but when "pip" is used you would need to use "--pre" in
> certain situations.  Currently, there is no need to talk about this as
> the default works the same way for both installers.

A tox.ini option to turn this on/off, with a backwards compatible
default and a big note that the default is going to change with the next
major version number bump (tox 2.0?) seems like the way to go.

I think it's useful to be able to test both with prereleases (to catch
upcoming issues, if PyPI prereleases catch on) and with final package
versions (to make sure your package works when your users attempt to pip
install it today).  For this reason I think it would be good to have
both a command-line switch and a tox.ini option to set the maintainer's
preferred default.

Marius Gedminas
-- 
My point today is that, if we wish to count lines of code, we should not regard
them as "lines produced" but as "lines spent": the current conventional wisdom
is so foolish as to book that count on the wrong side of the ledger.
        -- E. W. Dijkstra
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140930/2f5f556e/attachment.pgp>


More information about the testing-in-python mailing list