[Distutils] Builders vs Installers

[PJ Eby]

On Wed, Mar 27, 2013 at 6:55 PM, Donald Stufft <donald at stufft.io> wrote:
> I still think I prefer a setup.py develop or develop.py to invoke the build system for development builds

It's possible we're not talking about the same thing -- I notice you
keep mentioning "setup.py develop", which is entirely unrelated to the
scenarios I'm talking about.  "setup.py develop" is for installing
something *you* are working on/developing.  But depending on raw
source doesn't imply that you would be editing or developing that
source; it just means that you have a bleeding-edge dependency (which
might in turn have others), adding to your management overhead if you
have to know how to build an sdist for each of those dependencies
whenever you need a refresh.

So, I'm not talking about scenarios where a user obtains a source
checkout and does something with it, I'm talking about scenarios where
the developer of a package wants to declare a *dependency* on
*another* package that currently has to be fetched from revision
control.  So, in order to install *their* package (e.g. to their
staging/test server), the install system has to be able to fetch and
build from raw sources.


> Sorry my statement was a bit unclear, those people would all fall under actively working on that project (Zope in this case). I mean installs from VCS's should be discouraged for end users.

Define "end users".  ;-)

Here's a different example: there was a point at which I was actively
developing PEAK-Rules and somebody else was actively developing
something that used it.  That person wasn't developing PEAK-Rules, and
I wasn't part of their project, but they wanted up-to-the-minute
versions because I was making changes based on their use cases, which
they needed right away.  Are they an "end user"?  ;-)

You could argue that, well, that's just one project, except that what
if somebody *else* depends on *their* project, because they're also
doing bleeding edge development?

Well, that happened, too, because the consumer of PEAK-Rules was doing
a bleeding-edge library that *other* people were doing bleeding-edge
development against.  So now there were two levels of dependency on
raw sources.

If you don't support these kinds of scenarios, you slow the
community's development velocity.  Not too long ago, Richard Jones
posted a graph on r/Python showing how package registration took off
exponentially around the time easy_install was released.  I think that
this is in large part due to the increased development velocity
afforded by being able to depend on other packages at both development
*and* deployment time.  Even though most packages don't depend on the
bleeding edge (because they're not themselves the bleeding edge), for
individual development it's a godsend to be able to depend on your
*own* packages from revision control, without needing all kinds of
manual rigamarole to use them.

(This is also really relevant for private and corporate-internal
development scenarios.)