Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Leonardo Rochael Almeida]

On 17 March 2017 at 11:47, Paul Moore  wrote:

> On 17 March 2017 at 14:40, Nick Coghlan  wrote:
> > [...] whichever
> > version of "foo" is first on sys.path will "win", and you won't be able
> to
> > import from the other one (so you'll be able to import "foo.bar" or
> > "foo.baz", but not both). [...]
>
> Really? OK, I feel stupid now, I've been making a fuss over something
> that's actually not possible. I should have tested this. My apologies
> (in my defense, I could have sworn I remembered someone else making
> precisely this point sometime in the past, but I guess I'll have to
> put that down to advancing age and brain decay...)
>

Well, as Nick mentioned, if the `foo` Python package is a namespace package
in both foo 1.0 and foo 2.0 distributions, then, yes, both `bar` and `baz`
would be importable, and this is a case that should be documented somewhere.

So, your point is not without merit.

However, most projects with namespace packages tend to be careful with the
mapping between packages and dists as the namespace package itself then
becomes a shared space that should be populated carefully, so such an issue
should be exceedingly rare.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[David Wilson]

Hey Robin,

> What happens if other distros decide not to use this environment variable?
> Do I really want distro specific code in the package?

AFAIK this is seeing a great deal of use outside of Debian and even
Linux, for instance GCC also supports this variable.


> In short where does the distro responsibility and package maintainers
> boundary need to be?

I guess it mostly comes down to whether you'd like them to carry the
debt of a vendor patch to implement the behaviour for you in a way you
don't like, or you'd prefer to retain full control. :)  So it's more a
preference than a responsibility.


David
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[Freddy Rietdijk]

Nixpkgs [1] uses SOURCE_DATE_EPOCH as well. We can reproducibly build the
Python interpreter (and packages with [2]).

[1] https://github.com/NixOS/nixpkgs
[2] https://bitbucket.org/pypa/wheel/pull-requests/77


On Fri, Mar 17, 2017 at 6:46 PM, Matthias Klose  wrote:

> On 17.03.2017 18:19, Robin Becker wrote:
> > An issue has been raised for reportlab to support a specific environment
> > variable namely SOURCE_DATE_EPOCH. The intent is that we should get our
> time
> > from this variable rather than time.localtime(time.time()) so that
> produced
> > documents are more invariant.
> >
> > First off is this a reasonable request? The variable is defined by
> debian here
> > https://reproducible-builds.org/specs/source-date-epoch/
> >
> > What happens if other distros decide not to use this environment
> variable? Do I
> > really want distro specific code in the package?
> >
> > In addition we already have our own mechanism for making the produced
> documents
> > invariant although it might require an extension to support externally
> specified
> > date & time as in the debian variable.
> >
> > In short where does the distro responsibility and package maintainers
> boundary
> > need to be?
>
> the reproducible-builds thing is not just a Debian thing, it's supported by
> other distros and upstream projects.
>
> Matthias
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[Matthias Klose]

On 17.03.2017 18:19, Robin Becker wrote:
> An issue has been raised for reportlab to support a specific environment
> variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time
> from this variable rather than time.localtime(time.time()) so that produced
> documents are more invariant.
> 
> First off is this a reasonable request? The variable is defined by debian here
> https://reproducible-builds.org/specs/source-date-epoch/
> 
> What happens if other distros decide not to use this environment variable? Do 
> I
> really want distro specific code in the package?
> 
> In addition we already have our own mechanism for making the produced 
> documents
> invariant although it might require an extension to support externally 
> specified
> date & time as in the debian variable.
> 
> In short where does the distro responsibility and package maintainers boundary
> need to be?

the reproducible-builds thing is not just a Debian thing, it's supported by
other distros and upstream projects.

Matthias

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[Thomas Kluyver]

Flit already supports $SOURCE_DATE_EPOCH for building wheels.

I think the environment variable is a good idea: if it gets wide
support, you will be able to set a single thing to affect lots of
different build tools, rather than working out where you need to add
command line arguments to half a dozen different build steps.

Thomas

On Fri, Mar 17, 2017, at 05:33 PM, Matthias Bussonnier wrote:
> On Fri, Mar 17, 2017 at 10:19 AM, Robin Becker 
> wrote:
> > An issue has been raised for reportlab to support a specific environment
> > variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time
> > from this variable rather than time.localtime(time.time()) so that produced
> > documents are more invariant.
> >
> > First off is this a reasonable request? The variable is defined by debian
> > here https://reproducible-builds.org/specs/source-date-epoch/
> >
> > What happens if other distros decide not to use this environment variable?
> > Do I really want distro specific code in the package?
> 
> For what it is worth, it seem like it will make its way into CPython as
> well:
> https://github.com/python/cpython/pull/296
> 
> And IFAICT, this env variable naming is already more than just debian.
> 
> -- 
> M
> 
> 
> >
> > In addition we already have our own mechanism for making the produced
> > documents
> > invariant although it might require an extension to support externally
> > specified date & time as in the debian variable.
> >
> > In short where does the distro responsibility and package maintainers
> > boundary need to be?
> > --
> > Robin Becker
> > ___
> > Distutils-SIG maillist  -  Distutils-SIG@python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Ronny Pfannschmidt]

On 17.03.2017 15:35, Nick Coghlan wrote:
> On 17 March 2017 at 19:58, Ronny Pfannschmidt
>  > wrote:
>
> Hi everyone,
>
> while looking over the recent peps i noticed that we keep a few
> inherent inefficiencies in where to find dist-info folders
>
> because they include version numbers, to get a distribution we
> have to search for it
> which is no longer really sensible as we no longer have
> multi-version installation in any upcoming standard.
>
> Linux distros still use multi-version installation fairly regularly -
> it's how services like EPEL are able to offer parallel installs of
> frameworks and libraries that are also in base RHEL/CentOS without
> breaking anything.
>
> The associated code to populate __main__.__requires__ and hence get
> pkg_resources.require() to do the right thing isn't pretty, but it
> *does* work.
>
as far as i understood, such dreaded code just fixes up sys.path, and
thus the precedence will solve the issue
dropping version strings from dist info does not prevent walking
sys.path in order

so i don't think it will break anything.

note that im not talking about dropping general multi version install or
setuptools multi version install,
im talking about removing the version number from the dist-info folder
as for all installation schemes that use it, there is exactly one
version in precedence order on sys.path

Cheers, Ronny

> While I expect tech like virtual environments, Software Collections,
> FlatPak, Snappy, etc, to eventually get us to the point where even
> Linux distros don't need parallel installs into the system
> site-packages any more, we're still a *looong* way from it being
> reasonable to assume that we can just drop parallel install support
> from the Python packaging tools in general.
>
> Cheers,
> Nick.
>
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   
> |   Brisbane, Australia

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[Matthias Bussonnier]

On Fri, Mar 17, 2017 at 10:19 AM, Robin Becker  wrote:
> An issue has been raised for reportlab to support a specific environment
> variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time
> from this variable rather than time.localtime(time.time()) so that produced
> documents are more invariant.
>
> First off is this a reasonable request? The variable is defined by debian
> here https://reproducible-builds.org/specs/source-date-epoch/
>
> What happens if other distros decide not to use this environment variable?
> Do I really want distro specific code in the package?

For what it is worth, it seem like it will make its way into CPython as well:
https://github.com/python/cpython/pull/296

And IFAICT, this env variable naming is already more than just debian.

-- 
M


>
> In addition we already have our own mechanism for making the produced
> documents
> invariant although it might require an extension to support externally
> specified date & time as in the debian variable.
>
> In short where does the distro responsibility and package maintainers
> boundary need to be?
> --
> Robin Becker
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] reproducible builds

[Robin Becker]

An issue has been raised for reportlab to support a specific environment 
variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time 
from this variable rather than time.localtime(time.time()) so that produced 
documents are more invariant.


First off is this a reasonable request? The variable is defined by debian here 
https://reproducible-builds.org/specs/source-date-epoch/


What happens if other distros decide not to use this environment variable? Do I 
really want distro specific code in the package?


In addition we already have our own mechanism for making the produced documents
invariant although it might require an extension to support externally specified 
date & time as in the debian variable.


In short where does the distro responsibility and package maintainers boundary 
need to be?

--
Robin Becker
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Daniel Holth]

At least *.egg-info works without-a-version and will be written that way
when installed in development mode. As a shortcut when possible
pkg_resources would read the package name and version number from the
filename and not bother looking inside the metadata file until necessary. I
don't recall whether the same can be said of *.dist-info.

You will probably find that pkg_resources always does a listdir for each
entry on sys.path when it runs. You might not be able to avoid that.

On Fri, Mar 17, 2017 at 10:48 AM Paul Moore  wrote:

On 17 March 2017 at 14:40, Nick Coghlan  wrote:
> Unless the __init__.py has its own __path__ extension code, whichever
> version of "foo" is first on sys.path will "win", and you won't be able to
> import from the other one (so you'll be able to import "foo.bar" or
> "foo.baz", but not both). That's not an accident, it's behaviour that was
> deliberately kept for backwards compatibility reasons when PEP 420's
native
> namespace package support was being designed.

Really? OK, I feel stupid now, I've been making a fuss over something
that's actually not possible. I should have tested this. My apologies
(in my defense, I could have sworn I remembered someone else making
precisely this point sometime in the past, but I guess I'll have to
put that down to advancing age and brain decay...)

My apologies, I stand corrected.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Paul Moore]

On 17 March 2017 at 14:40, Nick Coghlan  wrote:
> Unless the __init__.py has its own __path__ extension code, whichever
> version of "foo" is first on sys.path will "win", and you won't be able to
> import from the other one (so you'll be able to import "foo.bar" or
> "foo.baz", but not both). That's not an accident, it's behaviour that was
> deliberately kept for backwards compatibility reasons when PEP 420's native
> namespace package support was being designed.

Really? OK, I feel stupid now, I've been making a fuss over something
that's actually not possible. I should have tested this. My apologies
(in my defense, I could have sworn I remembered someone else making
precisely this point sometime in the past, but I guess I'll have to
put that down to advancing age and brain decay...)

My apologies, I stand corrected.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Nick Coghlan]

On 18 March 2017 at 00:00, Paul Moore  wrote:

> As a theoretical example:
>
> foo 1.0 looks like this:
>
> foo
> __init__.py
> bar.py
>
> foo 2.0 moves the functionality of foo/bar.py into baz.py
>
> foo
> __init__.py
> baz.py
>
> Put both of these on sys.path, then you can successfully import
> foo.bar and foo.baz. Which is of course wrong. Furthermore, which
> version of foo/__init__.py gets imported depends on which version of
> foo is first on sys.path, so one of bar and baz will be using the
> wrong foo.
>

Unless the __init__.py has its own __path__ extension code, whichever
version of "foo" is first on sys.path will "win", and you won't be able to
import from the other one (so you'll be able to import "foo.bar" or
"foo.baz", but not both). That's not an accident, it's behaviour that was
deliberately kept for backwards compatibility reasons when PEP 420's native
namespace package support was being designed.

You only get the "you can import both of them" behaviour if "foo" is a
namespace package, at which point "foo" itself doesn't really have a
version any more.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Nick Coghlan]

On 17 March 2017 at 19:58, Ronny Pfannschmidt <
opensou...@ronnypfannschmidt.de> wrote:

> Hi everyone,
>
> while looking over the recent peps i noticed that we keep a few inherent
> inefficiencies in where to find dist-info folders
>
> because they include version numbers, to get a distribution we have to
> search for it
> which is no longer really sensible as we no longer have multi-version
> installation in any upcoming standard.
>
Linux distros still use multi-version installation fairly regularly - it's
how services like EPEL are able to offer parallel installs of frameworks
and libraries that are also in base RHEL/CentOS without breaking anything.

The associated code to populate __main__.__requires__ and hence get
pkg_resources.require() to do the right thing isn't pretty, but it *does*
work.

While I expect tech like virtual environments, Software Collections,
FlatPak, Snappy, etc, to eventually get us to the point where even Linux
distros don't need parallel installs into the system site-packages any
more, we're still a *looong* way from it being reasonable to assume that we
can just drop parallel install support from the Python packaging tools in
general.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Paul Moore]

On 17 March 2017 at 14:04, Ronny Pfannschmidt
 wrote:
> btw, thats irrelevant for dist-info
> either it gets found double and is a problem
> or its priority-overridden

Agreed this is not relevant for dist-info (and sorry for diverting the
discussion into a side-issue).

For dist-info I see no need to version it, and I'm +1 on the renaming
you propose.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Paul Moore]

On 17 March 2017 at 13:34, Donald Stufft  wrote:
> Hmm, I believe it generally works fine does it not? The only situations I
> can think of where it does something funny are:
>
> (1) PEP 420 namespace packages where a file was added or removed in one of
> the versions (since that is impossible to differentiate from two different
> projects using the same namespace)
> (2) Uninstalling/Installing the same package during the lifetime of a
> process (which is already going to break in weird ways).
>
> What scenarios are you seeing two installs of the same package into
> different sys.path directories fail?

I don't have an actual failure, although I do think I've seen reports
in the past - it's definitely something that's come up in previous
discussions.

As a theoretical example:

foo 1.0 looks like this:

foo
__init__.py
bar.py

foo 2.0 moves the functionality of foo/bar.py into baz.py

foo
__init__.py
baz.py

Put both of these on sys.path, then you can successfully import
foo.bar and foo.baz. Which is of course wrong. Furthermore, which
version of foo/__init__.py gets imported depends on which version of
foo is first on sys.path, so one of bar and baz will be using the
wrong foo.

IMO, of course, the answer is simply "don't do that". But I'm OK with
simply leaving things as they stand if no-one else thinks it's worth
making an issue of it.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Ronny Pfannschmidt]

btw, thats irrelevant for dist-info
either it gets found double and is a problem
or its priority-overridden

On 17.03.2017 15:00, Paul Moore wrote:
> On 17 March 2017 at 13:34, Donald Stufft  wrote:
>> Hmm, I believe it generally works fine does it not? The only situations I
>> can think of where it does something funny are:
>>
>> (1) PEP 420 namespace packages where a file was added or removed in one of
>> the versions (since that is impossible to differentiate from two different
>> projects using the same namespace)
>> (2) Uninstalling/Installing the same package during the lifetime of a
>> process (which is already going to break in weird ways).
>>
>> What scenarios are you seeing two installs of the same package into
>> different sys.path directories fail?
> I don't have an actual failure, although I do think I've seen reports
> in the past - it's definitely something that's come up in previous
> discussions.
>
> As a theoretical example:
>
> foo 1.0 looks like this:
>
> foo
> __init__.py
> bar.py
>
> foo 2.0 moves the functionality of foo/bar.py into baz.py
>
> foo
> __init__.py
> baz.py
>
> Put both of these on sys.path, then you can successfully import
> foo.bar and foo.baz. Which is of course wrong. Furthermore, which
> version of foo/__init__.py gets imported depends on which version of
> foo is first on sys.path, so one of bar and baz will be using the
> wrong foo.
>
> IMO, of course, the answer is simply "don't do that". But I'm OK with
> simply leaving things as they stand if no-one else thinks it's worth
> making an issue of it.
> Paul
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Donald Stufft]

> On Mar 17, 2017, at 9:25 AM, Paul Moore  wrote:
> 
> On 17 March 2017 at 12:50, Leonardo Rochael Almeida
>  wrote:
>> I'm +0 on this proposal (the lack of enthusiasm coming from the fact that
>> multiple projects will be affected), but I'm -lots on any proposal
>> forbidding installation of different versions in different directories.
> 
> The comment I made was simply that having different versions in
> different directories *both of which are on sys.path at the same time*
> is invalid - it is now, and nothing I suggested changed anything, I
> was just suggesting documenting that fact. (That setup might work, as
> long as *all* of the files in the "inactive" version are completely
> shadowed by the active version, and yes that's normally the case, but
> nothing in the import or packaging infrastructure makes sure that's
> the case, so there's a risk of unexpected bugs).
> 
> But whatever. If people don't want to document the restriction, that's
> OK. Doesn't mean it's going to work any better, of course :-)
> 
> Paul
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


Hmm, I believe it generally works fine does it not? The only situations I can 
think of where it does something funny are:

(1) PEP 420 namespace packages where a file was added or removed in one of the 
versions (since that is impossible to differentiate from two different projects 
using the same namespace)
(2) Uninstalling/Installing the same package during the lifetime of a process 
(which is already going to break in weird ways).

What scenarios are you seeing two installs of the same package into different 
sys.path directories fail?

—
Donald Stufft



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Paul Moore]

On 17 March 2017 at 12:50, Leonardo Rochael Almeida
 wrote:
> I'm +0 on this proposal (the lack of enthusiasm coming from the fact that
> multiple projects will be affected), but I'm -lots on any proposal
> forbidding installation of different versions in different directories.

The comment I made was simply that having different versions in
different directories *both of which are on sys.path at the same time*
is invalid - it is now, and nothing I suggested changed anything, I
was just suggesting documenting that fact. (That setup might work, as
long as *all* of the files in the "inactive" version are completely
shadowed by the active version, and yes that's normally the case, but
nothing in the import or packaging infrastructure makes sure that's
the case, so there's a risk of unexpected bugs).

But whatever. If people don't want to document the restriction, that's
OK. Doesn't mean it's going to work any better, of course :-)

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Freddy Rietdijk]

Users may want to split installations over multiple folders and creating a
working environment by merging them (through symlinks / PYTHONPATH /
sys.path / site / .pth). Python doesn't support multiple versions of the
same module during runtime, and therefore I don't see any benefit in
including a "unique" identifier like the version number (which in fact
isn't unique, because one could also have multiple instances of the same
version but e.g. build differently).

In any case, forbidding installation of different versions in different
directories is not possible because, as I mentioned, one can create an
environment by simply merging site-packages folders.

On Fri, Mar 17, 2017 at 1:50 PM, Leonardo Rochael Almeida <
leoroch...@gmail.com> wrote:

>
>
> On 17 March 2017 at 07:32, Paul Moore  wrote:
>
>> On 17 March 2017 at 09:58, Ronny Pfannschmidt > ronnypfannschmidt.de> wrote:
>> > [...]
>> > in order to address that i'd like to propose to switch
>> >
>> > from "{distribution}-{version}.dist-info/" to
>> "{distribution}.dist-info/"
>> >
>> > given that it has been used since quite a while i would prefer a quick
>> > feedback loop from the ML before thinking about writing a PEP.
>>
>> +1 from me. And maybe explicitly state that installing multiple
>> versions of a distribution is not supported. Although this opens a
>> somewhat larger can of worms, in that you can install different
>> versions in separate directories - say in system and user
>> site-packages - and that has subtle issues but is technically not
>> rejected at the moment.
>
>
> People today rely on being able to install different versions of packages
> already installed in other directories. System, vs User site-packages, as
> you mentioned is one example.
>
> The `--system-site-packages` switch to `virtualenv` is another. In my
> experience, many projects rely on pre-packaged hard-to-build system
> packages, while using virtualenv to install more up-to-date versions
> project dependencies.
>
> So maybe restrict it to stating that
>> installing multiple versions of a distribution *in the same directory*
>> is not supported and duck the bigger issue for now.
>>
>
> This is already the case everywhere. Even setuptools' `easy_install`,
> while capable of installing multiple versions of the same project in the
> same site-packages directory, is in reality installing each one to it's own
> `.egg` directory inside `site-packages` and can keep only one of
> them "active" at a time. ("active" meaning: importable without an explicit
> incantation to request a different installed version).
>
> I'm +0 on this proposal (the lack of enthusiasm coming from the fact that
> multiple projects will be affected), but I'm -lots on any proposal
> forbidding installation of different versions in different directories.
>
> Cheers,
>
> Leo
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Leonardo Rochael Almeida]

On 17 March 2017 at 07:32, Paul Moore  wrote:

> On 17 March 2017 at 09:58, Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
> > [...]
> > in order to address that i'd like to propose to switch
> >
> > from "{distribution}-{version}.dist-info/" to
> "{distribution}.dist-info/"
> >
> > given that it has been used since quite a while i would prefer a quick
> > feedback loop from the ML before thinking about writing a PEP.
>
> +1 from me. And maybe explicitly state that installing multiple
> versions of a distribution is not supported. Although this opens a
> somewhat larger can of worms, in that you can install different
> versions in separate directories - say in system and user
> site-packages - and that has subtle issues but is technically not
> rejected at the moment.


People today rely on being able to install different versions of packages
already installed in other directories. System, vs User site-packages, as
you mentioned is one example.

The `--system-site-packages` switch to `virtualenv` is another. In my
experience, many projects rely on pre-packaged hard-to-build system
packages, while using virtualenv to install more up-to-date versions
project dependencies.

So maybe restrict it to stating that
> installing multiple versions of a distribution *in the same directory*
> is not supported and duck the bigger issue for now.
>

This is already the case everywhere. Even setuptools' `easy_install`, while
capable of installing multiple versions of the same project in the same
site-packages directory, is in reality installing each one to it's own
`.egg` directory inside `site-packages` and can keep only one of
them "active" at a time. ("active" meaning: importable without an explicit
incantation to request a different installed version).

I'm +0 on this proposal (the lack of enthusiasm coming from the fact that
multiple projects will be affected), but I'm -lots on any proposal
forbidding installation of different versions in different directories.

Cheers,

Leo
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

[Paul Moore]

On 17 March 2017 at 09:58, Ronny Pfannschmidt
 wrote:
> while looking over the recent peps i noticed that we keep a few inherent
> inefficiencies in where to find dist-info folders
>
> because they include version numbers, to get a distribution we have to
> search for it
> which is no longer really sensible as we no longer have multi-version
> installation in any upcoming standard.
>
> in order to address that i'd like to propose to switch
>
> from "{distribution}-{version}.dist-info/" to "{distribution}.dist-info/"
>
> given that it has been used since quite a while i would prefer a quick
> feedback loop from the ML before thinking about writing a PEP.

+1 from me. And maybe explicitly state that installing multiple
versions of a distribution is not supported. Although this opens a
somewhat larger can of worms, in that you can install different
versions in separate directories - say in system and user
site-packages - and that has subtle issues but is technically not
rejected at the moment. So maybe restrict it to stating that
installing multiple versions of a distribution *in the same directory*
is not supported and duck the bigger issue for now.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [proposal] version-free + lookup-friendly dist-info location

[Ronny Pfannschmidt]

Hi everyone,

while looking over the recent peps i noticed that we keep a few inherent
inefficiencies in where to find dist-info folders

because they include version numbers, to get a distribution we have to
search for it
which is no longer really sensible as we no longer have multi-version
installation in any upcoming standard.

in order to address that i'd like to propose to switch

from "{distribution}-{version}.dist-info/" to "{distribution}.dist-info/"

given that it has been used since quite a while i would prefer a quick
feedback loop from the ML before thinking about writing a PEP.

-- Ronny

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig