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

[Carl Meyer]

On 09/29/2014 12:32 PM, 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? 

I am not sure that `pip install --pre` is a very useful CLI API
(probably the best argument for it is that it provides a way to easily
say "make pip behave like it used to"), but I do think that pip's move
to ignore non-final releases by default was a very good idea. I dealt
with many complaints over the years from PyPI authors who assumed that
if they had both 3.7 and 4.0a1 uploaded on PyPI, the toolchain would be
smart enough somehow for their users to get 3.7 by default.

> Are there many examples (besides Ned's) of people relying and using 
> that feature?

I don't have numbers (Donald might; CCed him since I'm not sure he is on
this list), but I have anecdotally heard from several different people
who now upload pre-releases of their packages to PyPI based on pip's new
behavior.

> 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/ )

Those numbers are a year old; it would be interesting to know how
they've changed. I would expect that distribute is much lower now, at least.

It would also be interesting to know how many of those easy_install
downloads come from things like `setup_requires` or the
auto-dependency-installation of `setup.py test`, as opposed to explicit
installations. I'm not sure there's any way to get this information, though.

For better or worse, my experience is that many PyPI authors are already
willing to ignore easy_install. With the advent of pip in the stdlib and
wheels for binary distribution on Windows, I think it's safe to assume
that its usage will continue to decrease.

And if its usage did not decrease for whatever reason, now that
setuptools is maintained by PyPA I would expect it to eventually follow
pip's lead on this issue. I'd guess the only reason this hasn't been
done already - and I'm making the assumption that it hasn't - is due to
the assumption that easy_install is now only used for legacy reasons,
and it's better to just leave legacy alone.

In summary: I think it's safe to say that "ignore non-final releases by
default" is now the preferred and expected behavior for Python
installers, and it will only become increasingly reasonable for authors
to depend on that behavior.

> - it is too coarse grained: it will drag in non-stable versions from
>   the full dependency closure you are installing, not just one.  So it's
>   usually better to have and maintain a "requirements.txt" with good 
>   version specifiers if you want stability and "referential integrity" 
>   between your tests and deployments.

Yes, I agree. Note that this is not an argument against "ignore
non-final releases by default". It is a good argument against `--pre` as
the method for pulling in non-final releases. The better method is to
specify the precise non-final release you want.

I am not sure that arguments against `--pre` form arguments for
continuing to use `--pre` in tox :-)

>> I suppose it would be possible (though probably ugly) to implement this
>> change with a deprecation-warning cycle.
> 
> If i'd go for it i'd suggest to directly change it in tox-1.9, adding a 
> "--pre" switch and a new default "install_command=pip install {opts}
> {packages}" where the "tox --pre" switch changes the contents of
> "{opts}".  And i'd ask the people here on the ML pushing for the change
> to submit a PR :)

That's fair :-) If you approve the idea I will write the PR.

Carl