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

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

Re: [Distutils] reproducible builds

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

Re: [Distutils] reproducible builds

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

Re: [Distutils] reproducible builds

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

Re: [Distutils] reproducible builds

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

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

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

Re: [Distutils] reproducible builds

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

[Distutils] reproducible builds

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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 >>

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

> 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

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

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

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

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

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

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 >

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

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

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

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