In article <mailman.10329.1401074189.18130.python-l...@python.org>,
Ben Finney <b...@benfinney.id.au> wrote:
> Roy Smith <r...@panix.com> writes:
> > Stefan Behnel <stefan...@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.
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.