Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 23 January 2016 at 08:17, Nathaniel Smith wrote: > On Fri, Jan 22, 2016 at 11:28 AM, Donald Stufft wrote: >> Yea, that’s why I thought about dpkg (system) or system(Debian) or >> something. The main reason I can think of for preferring “system” is if we >> don’t want to change the valid charac

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 22:07, M.-A. Lemburg wrote: > However, system vendors will often be a lot faster with updates > than package authors, simply because it's their business model, > so as user you will want to benefit from those updates and > not have to rely on the package author to ship new wh

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 2016-01-23 08:09:47 +1300 (+1300), Robert Collins wrote: [...] > Having a interface to the system package manager as has been > previously mooted - and I'm going to get back to that - might help a > little, but uninstalls are quite different to installs. Uninstalls get > blocked by things like '

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On Fri, Jan 22, 2016 at 11:28 AM, Donald Stufft wrote: > > On Jan 22, 2016, at 1:46 PM, Nathaniel Smith wrote: > > On Jan 22, 2016 10:11 AM, "Donald Stufft" wrote: > > > > PEP 376 added a file to the .dist-info directory called "INSTALLER" > which was > > supposed to be: > > > > This option

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 22 January 2016 at 20:45, Donald Stufft wrote: > Hmm, in my head the three cases were more like: > > 1) The installed project is managed by a Python level tool which uses the > Python metadata as it’s database. Thus if you’re this kind of tool too, then > you can muck around here because thin

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

> On Jan 22, 2016, at 3:38 PM, Paul Moore wrote: > > On 22 January 2016 at 18:46, Nathaniel Smith wrote: >>> I'd like to propose adding a special cased value to add to the installer >>> file >>> that will tell projects like pip that this particular installed thing is >>> being >>> managed by so

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 22 January 2016 at 18:46, Nathaniel Smith wrote: >> I'd like to propose adding a special cased value to add to the installer >> file >> that will tell projects like pip that this particular installed thing is >> being >> managed by someone else, and we should keep our hands off of it. According

Re: [Distutils] draft PEP: manylinux1

On Jan 22, 2016 9:04 AM, "Lowekamp, Bradley (NIH/NLM/LHC) [C]" < blowek...@mail.nih.gov> wrote: > > Hello, > > I noticed that libpython is missing from the lists of dependent libraries. Also the “manylinux” Docker image has it’s Python versions compiled with libpython static. > > Does this mean tha

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

> On Jan 22, 2016, at 2:09 PM, Robert Collins wrote: > > I think requiring a force flag to replace files installed by another > packaging tool is an unbreakme option as things stand, and so I'm very > concerned about the resulting user experience. I don't think the current behavior makes *any*

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

> On Jan 22, 2016, at 1:46 PM, Nathaniel Smith wrote: > > On Jan 22, 2016 10:11 AM, "Donald Stufft" > wrote: > > > > PEP 376 added a file to the .dist-info directory called "INSTALLER" which > > was > > supposed to be: > > > > This option is the name of the tool us

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 23 January 2016 at 07:10, Donald Stufft wrote: > PEP 376 added a file to the .dist-info directory called "INSTALLER" which was > supposed to be: > > This option is the name of the tool used to invoke the installation. > > However, nothing has really ever implemented it and it's gone largely

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On Jan 22, 2016 10:11 AM, "Donald Stufft" wrote: > > PEP 376 added a file to the .dist-info directory called "INSTALLER" which was > supposed to be: > > This option is the name of the tool used to invoke the installation. > > However, nothing has really ever implemented it and it's gone largel

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On Fri, Jan 22, 2016 at 12:10 PM, Donald Stufft wrote: > PEP 376 added a file to the .dist-info directory called "INSTALLER" which was > supposed to be: > > This option is the name of the tool used to invoke the installation. > > However, nothing has really ever implemented it and it's gone la

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On Fri, Jan 22, 2016 at 1:10 PM, Donald Stufft wrote: > Does this sound reasonable to everyone? Do we think it needs a new > PEP or can we just amend PEP 376 to add this extra bit of information? Identifying something special like "system" doesn't seem bad, and conforms (assuming PEP 376 really m

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

On 22 January 2016 at 18:10, Donald Stufft wrote: > The benefit of doing this, is that with a special value in that file that says > "this file belongs to the OS", then pip could start looking for that file and > require a --force flag before it modifies any files belonging to that project. > Then

[Distutils] PEP 376, the INSTALLER file, and system packages

PEP 376 added a file to the .dist-info directory called "INSTALLER" which was supposed to be: This option is the name of the tool used to invoke the installation. However, nothing has really ever implemented it and it's gone largely ignored until just recently pip 8.0 started writing the INST

Re: [Distutils] draft PEP: manylinux1

Hello, I noticed that libpython is missing from the lists of dependent libraries. Also the “manylinux” Docker image has it’s Python versions compiled with libpython static. Does this mean that we must do static linking against libpython? If so, can’t this cause problems with mixing Python objec

Re: [Distutils] Package classifiers - both major and minor Python versions?

On Fri, Jan 22, 2016 at 2:57 AM, Chris Jerdonek wrote: > If "Python 2" really means that all 2.x versions are supported as > opposed to just some, then that should also be clarified (and > similarly for "Python 3"). Bingo! That's the main point, I think. Because there's no single reference for

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 11:55, Donald Stufft wrote: >> From the point of view of future-proofing PEP 513 against having such >> an alternative available in the future, the main question that would >> need to be considered is how tools would decide download priority >> between a distro-specific wheel

Re: [Distutils] draft PEP: manylinux1

On 22.01.2016 12:25, Donald Stufft wrote: > >> On Jan 22, 2016, at 5:48 AM, M.-A. Lemburg wrote: >> >> Embedding additional libraries in the wheels files to overcome >> deficiencies in the PEP design simply doesn't feel right >> to me. >> >> People who rely on Linux distributions want to continue

Re: [Distutils] draft PEP: manylinux1

> On Jan 22, 2016, at 6:29 AM, Nick Coghlan wrote: > > On 22 January 2016 at 20:48, M.-A. Lemburg wrote: >> People who rely on Linux distributions want to continue >> to do so and get regular updates for system packages from >> their system vendor. Having wheel files override these >> system pa

Re: [Distutils] draft PEP: manylinux1

2016-01-22 3:47 GMT+01:00 Chris Barker - NOAA Federal : > > Maybe the community will spring forth and do that -- I'm skeptical because I > tried to to that for years for OS-X and it was just too much to do. And the > infrastructure was there. > > Before pip and wheel there were mpkgs on OS-X, and r

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 21:25, Donald Stufft wrote: > Thinking of it in terms of a C like "undefined behavior" is probably a > reasonable way of doing it. Linking against a system provided library that is > on this list is a defined behavior of the manylinux "platform", linking > against > somethin

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 20:48, M.-A. Lemburg wrote: > People who rely on Linux distributions want to continue > to do so and get regular updates for system packages from > their system vendor. Having wheel files override these > system packages by including libs directly in the wheel > silently brea

Re: [Distutils] draft PEP: manylinux1

> On Jan 22, 2016, at 5:48 AM, M.-A. Lemburg wrote: > > Embedding additional libraries in the wheels files to overcome > deficiencies in the PEP design simply doesn't feel right > to me. > > People who rely on Linux distributions want to continue > to do so and get regular updates for system pa

Re: [Distutils] draft PEP: manylinux1

On 22.01.2016 11:03, Nathaniel Smith wrote: > On Fri, Jan 22, 2016 at 1:33 AM, M.-A. Lemburg wrote: >> On 21.01.2016 20:05, Matthew Brett wrote: >>> Hi, >>> >>> On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: On 21.01.2016 10:31, Nick Coghlan wrote: > On 21 January 2016 at 19:03, M

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 19:33, M.-A. Lemburg wrote: > For example, if a package needs a specific version of libpng, > the package author can document this and the user can then make > sure to install that particular version. The assumption that any given Python user will know how to do this is not

Re: [Distutils] draft PEP: manylinux1

On Fri, Jan 22, 2016 at 1:33 AM, M.-A. Lemburg wrote: > On 21.01.2016 20:05, Matthew Brett wrote: >> Hi, >> >> On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: >>> On 21.01.2016 10:31, Nick Coghlan wrote: On 21 January 2016 at 19:03, M.-A. Lemburg wrote: > By using the version base

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 20:05, Matthew Brett wrote: > Hi, > > On Thu, Jan 21, 2016 at 2:05 AM, M.-A. Lemburg wrote: >> On 21.01.2016 10:31, Nick Coghlan wrote: >>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run into this problem and gain a lot

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 07:04, Matthew Brett wrote: >> That's an interesting idea, but I personally don't see the manylinux1 list >> as particularly >> "scientific". If anything, I'd call it "minimal". > > Yes, I agree, I don't think 'linux-sciabi1" would differentiate this > from other ways of buil

Re: [Distutils] draft PEP: manylinux1

On 22 January 2016 at 17:04, Matthew Brett wrote: > Hi, > On Thu, Jan 21, 2016 at 7:45 PM, Robert T. McGibbon > wrote: >> On Thu, Jan 21, 2016 at 7:32 PM, Nick Coghlan wrote: >>> However, it does suggest a possible alternative approach to naming >>> these compatibility subsets: what if the name