[Distutils] Future of setuptools and buildout
dholth at gmail.com
Tue Aug 16 13:11:10 EDT 2016
There are two proposals to add pluggable build systems to Python sdists,
and one of them will probably be implemented. You add a pyproject.toml to
the root of your sdist, which the installer uses to install dependencies
that setup.py itself needs to run. Second, you also tell pip which build
system you are using, once you have done that, setup.py is no longer
necessary - instead, pip could install and then invoke flit for example.
This isn't quite the situation you've outlined as setuptools will likely
continue to have all its features. Instead, packages that don't use
setuptools will also proliferate. It causes about the same problem for
buildout without breaking older packages.
In this scenario buildout will need to be able to install wheels however it
wishes to do so because that is the output of the pluggable build system. I
don't have advice for you on the implementation, except perhaps it could
call out to pip.
On Tue, Aug 16, 2016 at 12:59 PM Leonardo Rochael Almeida <
leorochael at gmail.com> wrote:
> Spinning this off into its own thread...
> On 16 August 2016 at 13:10, Donald Stufft <donald at stufft.io> wrote:
>> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida <
>> leorochael at gmail.com> wrote:
>> Specifically, buildout right now has setuptools as its only dependence,
>> and buildout uses it to locate, download and build sdist dependencies, or
>> directly download and use .egg dependencies, which are important for
>> Windows platforms in the communities that use buildout and depend on
>> compiled extensions.
>> Ah, I knew I was forgetting something. I think we should hold off on
>> preventing egg uploads until setuptools can download and install wheels.
> Which brings us to a question that I'm meaning to ask for a while.
> It looks like we're close to removing all mentions of setuptools in pip.
> When this happens, it looks like pressure is going to start to mount on
> setuptools to drop the ability to install packages and limit itself on
> being just a build tool.
> It makes sense that it should be so, considering that there would be no
> incentive to keep around two distinct implementations of how to locate,
> download and install stuff, one in pip (or whatever library pip uses for
> locating and installing packages) and another in setuptools.
> In this future, I can imagine setuptools will simply complain loudly when
> the packages it requires to do its work are not installed yet, perhaps with
> a plugin mechanism for allowing another package to automatically resolve
> and installing packages, (like today setuptools-git extends setuptools to
> recognize files from git to be included in a package).
> And people will promptly write a pip implementation of this plugin (or
> whatever it is that pip will use as a library to do it)... thereby
> inverting the dependency between setuptools and pip.
> When this future arrives, buildout will be out of a mechanism for
> locating, downloading and installing packages (not counting old versions of
> setuptools, of course).
> 1. Is the future outlined above considered likely?
> 2. If this future arrives, what package should buildout be ported to use?
> It should provide:
> * The ability to locate packages and their versions, resolve their
> dependencies, and download them, whether they're sdists or wheels (or eggs,
> while we still have them)
> * Install each package separately into it's own directory that, if added
> to `sys.path`, allows this same package (or perhaps another one) to read
> information from entry points so that buildout can locate its own
> extensions and install console scripts.
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG