Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

[Roy Smith]

In article <mailman.10329.1401074189.18130.python-list at python.org>,
 Ben Finney <ben at benfinney.id.au> wrote:

> Roy Smith <roy at panix.com> writes:
> 
> > Stefan Behnel <stefan_ml at behnel.de> wrote:
> >
> > > And I don't really see why you would consider fabric a dependency
> > > that keeps you from switching to Py3. In many cases, you can just
> > > keep running it in Py2 as you did before.
> >
> > In theory, that's possible. In practice, it would mean having to
> > maintain two different versions of Python
> 
> Why would using Fabric – a build tool – require you to “maintain two
> different versions of Python”? You only need to maintain the build
> scripts, not Python itself.

Because to run these tools, we need have both versions installed on 
every machine.  So, we don't need to maintain Python in the sense of 
building it from source, but we do need to have our deployment scripts 
install it everyplace it's needed (or, at least, make sure it's 
installed as part of some base deployment package)

> > and test everything against both.
> 
> That makes even less sense. The build system runs under whatever version
> of Python it needs, and your code runs under whatever version of Python
> you like. The two don't affect each other at run time, and don't affect
> each other's testing dependencies.

The are tightly integrated, and share code.

> At least one of us seems to be misunderstanding what is required.

Yes :-)

When you start working with large systems, reducing complexity becomes 
important.  Every time you add a component, it comes with its own set of 
dependencies and constraints.  Those things come back to bite you when 
you least expect it.