Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 21:15, Thomas Kluyver wrote: > On 12 October 2015 at 05:37, Robert Collins > wrote: >> >> And a bugfix :) - I didn't link to the docs for the build system >> interface we have today - >> >>

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 19:23, Ralf Gommers wrote: > > > On Mon, Oct 12, 2015 at 6:37 AM, Robert Collins > wrote: >> >> On 12 October 2015 at 17:06, Robert Collins >> wrote: >> > EWOW, huge thread. >> > >> > I've read

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I could be wrong but if egg-info actually generated a dist-info directory it would probably still work. On Mon, Oct 12, 2015 at 8:50 AM Thomas Kluyver wrote: > On 12 October 2015 at 05:37, Robert Collins > wrote: > >> And a bugfix :) - I didn't link

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 05:37, Robert Collins wrote: > And a bugfix :) - I didn't link to the docs for the build system > interface we have today - > https://pip.pypa.io/en/latest/reference/pip_install/#build-system-interface > I'm happy to see that the command line

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, Oct 12, 2015 at 6:37 AM, Robert Collins wrote: > On 12 October 2015 at 17:06, Robert Collins > wrote: > > EWOW, huge thread. > > > > I've read nearly all of it but in order not to make it massively > > worse, I'm going to reply to

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 11, 2015 11:07 PM, "Robert Collins" wrote: > > EWOW, huge thread. > > I've read nearly all of it but in order not to make it massively > worse, I'm going to reply to all the points I think need raising in > one mail :). > > Top level thoughts here, more point

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 11:01, Robert Collins wrote: > Python packaging config in $root/pypa.yaml > > Defined keys: > > ... > build-tool: > # basic command that will spit a hunk of json back to the caller > defining the > # commands to use with the build tool. >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 13 October 2015 at 06:23, Nathaniel Smith wrote: > On Oct 12, 2015 10:16 AM, "Robert Collins" > wrote: ... >> So until we solve the problems related to unloading something loaded >> into Python and loading a different version in and all the related

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 13 October 2015 at 01:52, Daniel Holth wrote: > I could be wrong but if egg-info actually generated a dist-info directory it > would probably still work. I'd worry about fallout - since pip doesn't need to change (much) either way, I'd be inclined to be specific and allow

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 13 October 2015 at 02:33, Thomas Kluyver wrote: > On 12 October 2015 at 11:01, Robert Collins > wrote: >> >> Python packaging config in $root/pypa.yaml >> >> Defined keys: >> >> ... >> build-tool: >> # basic command that will spit a hunk of

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 12, 2015 10:16 AM, "Robert Collins" wrote: > > On 13 October 2015 at 02:33, Thomas Kluyver wrote: > > On 12 October 2015 at 11:01, Robert Collins > > wrote: > >> > >> Python packaging config in $root/pypa.yaml > >> >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 11 October 2015 at 05:01, Nathaniel Smith wrote: > There's no formal proposal because it doesn't involve distutils-sig -- > it's something that we already know how to do and are working on > implementing :-). The only reason it doesn't already exist on PyPI is > that Windows is

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 12 October 2015 at 17:06, Robert Collins wrote: > EWOW, huge thread. > > I've read nearly all of it but in order not to make it massively > worse, I'm going to reply to all the points I think need raising in > one mail :). And a bugfix :) - I didn't link to the docs

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

EWOW, huge thread. I've read nearly all of it but in order not to make it massively worse, I'm going to reply to all the points I think need raising in one mail :). Top level thoughts here, more point fashion with only rough editing below the fold. I realise many things - like the issue between

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10 October 2015 at 04:47, Chris Barker wrote: > So the question is: if I compile my third party package against numpy and > mkl, it would depend on numpy and py_mkl. > > If I went to installed this on a system that had a numpy that depends on > openblas, pip would

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, Oct 7, 2015 at 2:41 PM, Paul Moore wrote: [...] > Possibly the nearest > we'd have to an issue is over allowing the build process to *add* > dependencies to a binary wheel (e.g. a some builds depend on > currently-hypothetical MKL wheel, which provides needed DLLs). I

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 10:04 AM, Chris Barker wrote: > 1) what in the world is a "source wheel"? And how is it different than an > sdist (other than maybe in a different file format. It seemed like people had different ideas about what a platonic "sdist" even is and this

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I'd also like to join Am 9. Oktober 2015 06:29:58 MESZ, schrieb Robert Collins : >Toss me an invite too - I'm very interested in this, for all that I >havent' kibbitzed on the thread yet :) > >On 9 October 2015 at 05:33, Nathaniel Smith wrote: >> On

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

How many people can join a hangout? we may be bumping up against that limit :-) -CHB On Thu, Oct 8, 2015 at 12:58 PM, Nathaniel Smith wrote: > On Oct 8, 2015 09:33, "Nathaniel Smith" wrote: > > > > On Oct 8, 2015 8:14 AM, "Nathaniel Smith"

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 7:05 PM, Chris Barker wrote: > How many people can join a hangout? we may be bumping up against that > limit :-) ​AFAIK there's no limit on the number of people that can listen in. Also, Hangouts can record video (the "On Air" thing).​ Thanks,

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 9 October 2015 at 18:04, Chris Barker wrote: > Which seems to point more to having an optional "binary_build" component to > the name. Not sure what syntax is available, but the idea would be that: > > "numpy|mkl" > > and > > "numpy|openblas" > > would both match "numpy"

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Listening in to an On Air session is unbounded, but direct participants are capped at 10. On Fri, 9 Oct 2015 at 09:17 Ionel Cristian Mărieș wrote: > > On Fri, Oct 9, 2015 at 7:05 PM, Chris Barker > wrote: > >> How many people can join a hangout? we

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I"ve been following this thread and gotten a bit lost. But I do care, because I'm a heavy numpy user, and also because I was involved for years in building pacakges for OS-X, and currently need distribute some of my own stuff that has semi-ugly C lib dependencies (Not as ugly as BLAS.,though :-) )

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 9 October 2015 at 18:04, Chris Barker wrote: > 1) what in the world is a "source wheel"? And how is it different than an > sdist (other than maybe in a different file format. A "source wheel" is the proposed name for a to-be-defined replacement for sdists. For now, you

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, 9 Oct 2015 19:01 Carl Meyer wrote: On 10/09/2015 11:18 AM, Paul Moore wrote: > On 9 October 2015 at 18:04, Chris Barker wrote: >> 1) what in the world is a "source wheel"? And how is it different than an >> sdist (other than maybe in a different

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static and each wheel declares its own dependencies > statically but differently. Am I

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, 9 Oct 2015 19:35 Carl Meyer wrote: On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static and each wheel

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 12:44 PM, Oscar Benjamin wrote: > > On Fri, 9 Oct 2015 19:35 Carl Meyer > wrote: > > On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > > Why would it need dynamic metadata for the windows matplotlib wheel to > > have different

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 11:18 AM, Paul Moore wrote: > On 9 October 2015 at 18:04, Chris Barker wrote: >> 1) what in the world is a "source wheel"? And how is it different than an >> sdist (other than maybe in a different file format. > > A "source wheel" is the proposed name for a

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 10:28 AM, Paul Moore wrote: > ... or thinking again, maybe you mean having multiple packages > (numpy_mkl, numpy_openblas, ...) all of which satisfy a "numpy" > requirement? yes, that is EXACTLY what I meant. the idea here is that if you build a

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 11:28 AM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static and each wheel declares its own dependencies >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 11:44 AM, Oscar Benjamin wrote: > Assuming it's tied to the operating system it doesn't matter surely. When > pip runs on Windows it can ignore dependencies that apply to other > platforms so I don't see how this case makes it more complex. >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 22:41, Paul Moore wrote: > On 7 October 2015 at 22:28, Nathaniel Smith wrote: >> Maybe I have misunderstood: does it actually help pip at all to have >> static access to name and version, but not to anything else? I've been >> assuming

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin wrote: > I think this satisfies all of the requirements for static metadata and > one-to-one correspondence of source wheels and binary wheels. If numpy > followed this then I imagine that there would be a single source

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 11:18, Oscar Benjamin wrote: > On 7 October 2015 at 22:41, Paul Moore wrote: >> On 7 October 2015 at 22:28, Nathaniel Smith wrote: >>> Maybe I have misunderstood: does it actually help pip at all to have >>>

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 8, 2015 at 8:48:16 AM, Oscar Benjamin (oscar.j.benja...@gmail.com) wrote: > On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote: > > On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin > > wrote: > >> > >> I think this satisfies all of the requirements for static metadata and > >>

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote: > On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin > wrote: >> >> I think this satisfies all of the requirements for static metadata and >> one-to-one correspondence of source wheels and binary

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 13:39, Oscar Benjamin wrote: > On 8 October 2015 at 12:46, Paul Moore wrote: >> On 8 October 2015 at 11:18, Oscar Benjamin >> wrote: >>> >>> A concrete example would be whether or not the numpy

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Thu, Oct 8, 2015 at 4:51 PM, Oscar Benjamin wrote: > It depends. If you're using numpy from pure Python code the difference > between mkl and otherblas is probably irrelevant. So in most cases > you'd want to be able to depend just on "numpy" but in some cases >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 12:46, Paul Moore wrote: > On 8 October 2015 at 11:18, Oscar Benjamin wrote: >> >> A concrete example would be whether or not the numpy source wheel >> depends on pyopenblas. Depending on how numpy is built the binary >> wheel

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote: > One of the features in the original PEP was the ability to produce multiple > different Wheels from the same source release much like how Debian does. > e.g. > numpy-1.0.newsdistthing could produce numpy-pyopenblas-12.6.whl

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 14:34, Ionel Cristian Mărieș wrote: > > On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote: >> >> One of the features in the original PEP was the ability to produce >> multiple >> different Wheels from the same source release much like

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 8, 2015 9:23 AM, "Ionel Cristian Mărieș" wrote: > > > On Thu, Oct 8, 2015 at 4:51 PM, Oscar Benjamin wrote: >> >> It depends. If you're using numpy from pure Python code the difference >> between mkl and otherblas is probably irrelevant. So

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote: > > On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote: > > > Yeah, that's not a good long term solution -- it needs to be moved > > into the metadata (probably by creating an MKL wheel and then > > making > >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 8, 2015 8:34 AM, "Ionel Cristian Mărieș" wrote: > > > On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote: >> >> One of the features in the original PEP was the ability to produce multiple >> different Wheels from the same source release much like how

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

> > But the different builds for the different configurations end up with > different metadata. If I'm understanding right, the whole point of > "source wheels" is that they have all the static metadata that pip > needs in order to make decisions, and this has to match the resulting > wheels --

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote: > > On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote: > > > > On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote: > > > > Yeah, that's not a good long term solution -- it needs to be moved > > >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Toss me an invite too - I'm very interested in this, for all that I havent' kibbitzed on the thread yet :) On 9 October 2015 at 05:33, Nathaniel Smith wrote: > On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote: >> >> On Oct 7, 2015 2:58 PM, "Donald Stufft"

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 8, 2015 09:33, "Nathaniel Smith" wrote: > > On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote: > > > > On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote: > > > > > > On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote: > >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 22:53, Nathaniel Smith wrote: >> I think I'm as confused by what you're saying here as Donald is. Could >> you give a few examples of such projects? I'd like to go & take a look >> at them and try to understand what they are doing that is so >> incompatible

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 20:36, Oscar Benjamin wrote: > Currently I can take the code from the numpy release and compile it in > different incompatible ways. For example I could make a wheel that bundles a > BLAS library. Or I could make a wheel that expects to use a

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, Oct 7, 2015 at 11:14 AM, Paul Moore wrote: > On 7 October 2015 at 18:27, Nathaniel Smith wrote: >> There are projects on PyPI right now, today, that have no way to >> generate sdists and will never have any need for "source wheels" > > I think I'm as

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 22:28, Nathaniel Smith wrote: > Maybe I have misunderstood: does it actually help pip at all to have > static access to name and version, but not to anything else? I've been > assuming not, but I don't think anyone's pointed to any examples yet > of the

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, Oct 7, 2015 at 1:28 PM, Paul Moore wrote: > The disconnect here seems to be that I view all of those wheels as > being numpy 1.9.X wheels (or whatever). They differ in terms of > compatibility details, but they are all wheels for the same > project/version. So there's

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote: > > Yeah, that's not a good long term solution -- it needs to be moved > into the metadata (probably by creating an MKL wheel and then > making > the numpy wheel depend on it). That's exactly the problem :-) >  Are

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, 7 Oct 2015 19:42 Donald Stufft wrote: On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benja...@gmail.com) wrote: > > > Your idea of an sdist as something that has fully static build/runtime > dependency metadata and a one to one correspondence with binary >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote: [...] > I also don't think it will be confusing. They'll associate the VCS thing (a > source release) as something focused on development for most everyone. Most > people won't explicitly make one and nobody will be

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (n...@pobox.com) wrote: > On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote: > [...] > > I also don't think it will be confusing. They'll associate the VCS thing (a > > source release) > as something focused on development for most everyone.

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 18:27, Nathaniel Smith wrote: > There are projects on PyPI right now, today, that have no way to > generate sdists and will never have any need for "source wheels" I think I'm as confused by what you're saying here as Donald is. Could you give a few examples

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, 7 Oct 2015 18:51 Donald Stufft wrote: On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (n...@pobox.com) wrote: > On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote: > [...] > > I also don't think it will be confusing. They'll associate the VCS thing (a source

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benja...@gmail.com) wrote: > > > Your idea of an sdist as something that has fully static build/runtime > dependency metadata and a one to one correspondence with binary > wheels is not a usable format when releasing the code for e.g. >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Sat, Oct 3, 2015 at 10:50 AM, Donald Stufft wrote: > I feel like you have some sort of "a sdist is jsut a tarball of a VCS" > mentality and I don't think that idea of a sdist is generally useful. Hmm, so, between thinking this over more on the plane today and reading your

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 5 October 2015 at 07:29, Nathaniel Smith wrote: > First, let's drop the word "sdist", it's confusing. I'll read your full reply later, when I have the time, but please note we can't drop the term sdist - it's a well known concept in packaging. Having said that, I'm happy if

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 9:11:59 AM, Paul Moore (p.f.mo...@gmail.com) wrote: > On 5 October 2015 at 13:44, Donald Stufft wrote: > > [3] Unlike Paul, I think a Source Wheel is actually a decent name for this > > concept. It's similar to .rpm and .src.rpm in that world, and I think it > > makes it more

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 08:44:04 -0400 Donald Stufft wrote: > > I don't think that it makes sense for pip to go directly from a VCS[1] to a > Wheel in the grand scheme of things. Right now we kind of do it, but that's > because we just treat them like an unpacked sdist [2], long

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

OK, I've had a better read of your email now. Responses inline. On 5 October 2015 at 07:29, Nathaniel Smith wrote: > First, let's drop the word "sdist", it's confusing. We can't (see below for details). We can deprecate the sdist concept, if that's what you want to propose. From

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Axle? On Mon, Oct 5, 2015 at 9:25 AM Donald Stufft wrote: > On October 5, 2015 at 9:11:59 AM, Paul Moore (p.f.mo...@gmail.com) wrote: > > On 5 October 2015 at 13:44, Donald Stufft wrote: > > > [3] Unlike Paul, I think a Source Wheel is actually a decent name for > this > > >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 14:11:56 +0100 Paul Moore wrote: > > Being a Windows user, I hadn't caught the parallel between > Wheel-Source wheel and RPM-Source RPM (is there also a similar > deb-source deb pair?) > > But if the concept works for people with a Linux background, I'm

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 5 October 2015 at 13:44, Donald Stufft wrote: > [3] Unlike Paul, I think a Source Wheel is actually a decent name for this > concept. It's similar to .rpm and .src.rpm in that world, and I think it > makes it more obvious that this item isn't an installable item in

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 2:29:35 AM, Nathaniel Smith (n...@pobox.com) wrote: > > Does that sound right? Off the bat, I'm perfectly fine with `pip install archive-made-from-vcs.tar.gz` working the same as `pip install git+https://github.com/foo/bar.git``. The fact that one is a VCS and one isn't is

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 5 October 2015 at 14:25, Donald Stufft wrote: > The main thing I wanted was something that wasn't a mouthful to say and that > had a dedicated extension so we don't end up where the filename looks > incredibly generic (requests-1.0.swhl vs requests-1.0.tar.gz). You find

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 09:28:48 -0400 Donald Stufft wrote: > > > > In any case, sdists being apt for human consumption is an important > > feature IMHO. > > > > I don't think so. Remember in my footnote I mentioned that I wasn't using VCS > to mean literally "something checked

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 9:45:29 AM, Wes Turner (wes.tur...@gmail.com) wrote: > > > How about something like > .sdist.whl.zip ? > > > There are already many tools with e.g. ZIP MIME extensions > so that one can open the file and browse the archive with a file > explorer > without a platform

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 10:52:22 AM, Antoine Pitrou (solip...@pitrou.net) wrote: > On Mon, 5 Oct 2015 09:51:05 -0400 > Donald Stufft wrote: > > > > You can see these needs are different I think by looking at how what > > Nathaniel wants differs > from what me and Paul want. He wants something

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 9:25:24 AM, Antoine Pitrou (solip...@pitrou.net) wrote: > On Mon, 5 Oct 2015 08:44:04 -0400 > Donald Stufft wrote: > > > > I don't think that it makes sense for pip to go directly from a VCS[1] to a > > Wheel in the grand scheme of things. Right now we kind of do it, but

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Because the status quo, which is a single format, sucks. I don't think changing it so we invoke a Python function instead of a script is going to make it not suck. The fundamental reason it sucks (in my mind) is that we have a single format trying to do way too many things and we need to break

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 5, 2015 8:41 AM, "Paul Moore" wrote: > > On 5 October 2015 at 14:25, Donald Stufft wrote: > > The main thing I wanted was something that wasn't a mouthful to say and that > > had a dedicated extension so we don't end up where the filename looks > >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 09:51:05 -0400 Donald Stufft wrote: > > You can see these needs are different I think by looking at how what > Nathaniel wants differs from what me and Paul want. He wants something that > will make the human side easier and will support different tools, we

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

The OP asks for a Python callable interface to pip instead of setup.py's command line interface. That could be accomplished now by figuring out all of the arguments that pip will send to setup.py (setup.py egg_info and setup.py bdist_wheel)?, and then by writing a setup.py emulator that implements

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 9:41:28 AM, Paul Moore (p.f.mo...@gmail.com) wrote: > On 5 October 2015 at 14:25, Donald Stufft wrote: > > The main thing I wanted was something that wasn't a mouthful to say and that > > had a dedicated extension so we don't end up where the filename looks > > incredibly

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 2015-10-05 15:39:10 +0200 (+0200), Antoine Pitrou wrote: [...] > But why use two different formats for "source release" and "sdists"? > Currently sdists fit the assumptions for a source release, why > introduce some complexity and have the users deal with separate > concepts (with all the

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 5, 2015 at 12:05:53 PM, Daniel Holth (dho...@gmail.com) wrote: > sdists work well most of the time. Some problems > > 1 - hard to depend on something setup.py must import > 2 - hard to use non-distutils build system due to the first problem and a > poorly defined command line interface

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

sdists work well most of the time. Some problems 1 - hard to depend on something setup.py must import 2 - hard to use non-distutils build system due to the first problem and a poorly defined command line interface 3 - have to regenerate metadata to get dependencies Assume we are not ever going

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Sat, Oct 3, 2015 at 10:50 AM, Donald Stufft wrote: > On October 2, 2015 at 10:27:36 PM, Nathaniel Smith (n...@pobox.com) wrote: >> >> So I'm extremely reluctant to give up on standardizing how to handle >> VCS checkouts. And if we're going to have a standard for that, then >>

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Let me see if I can help clarify, so it's not just Donald who says so :-) It does feel as if we're trying to explain a lot of things that "everybody knows". Clearly not everybody knows, as you don't, but what we're trying to clarify here is the de facto realities of how sdists work, and how

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 4, 2015 at 2:22:51 PM, Nathaniel Smith (n...@pobox.com) wrote: > > I guess to make progress in this conversation I need some more > detailed explanations. I totally get that there's a long history > of thought and conversations behind the various assertions > here like "a sdist is

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 3 October 2015 at 02:03, Nathaniel Smith wrote: > In particular I hesitate a little bit to just drop in everything from > PEP 426 and friends, because previous specs haven't really thought > through the distinction between sdists and wheels -- e.g. if an sdist > generates two

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Sat, 3 Oct 2015 at 04:51 Paul Moore wrote: > On 3 October 2015 at 02:03, Nathaniel Smith wrote: > > In particular I hesitate a little bit to just drop in everything from > > PEP 426 and friends, because previous specs haven't really thought > > through

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 2, 2015 at 10:27:36 PM, Nathaniel Smith (n...@pobox.com) wrote: > > So I'm extremely reluctant to give up on standardizing how to handle > VCS checkouts. And if we're going to have a standard for that, then > would sure be nice if we could share the work between this standard > and the

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Oct 3, 2015 12:36 PM, "Donald Stufft" wrote: > > > > On October 3, 2015 at 1:31:48 PM, Brett Cannon (br...@python.org) wrote: > > On Sat, 3 Oct 2015 at 04:51 Paul Moore wrote: > > > > > On 3 October 2015 at 02:03, Nathaniel Smith wrote: > > > > In particular I hesitate a

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 3, 2015 at 1:31:48 PM, Brett Cannon (br...@python.org) wrote: > On Sat, 3 Oct 2015 at 04:51 Paul Moore wrote: > > > On 3 October 2015 at 02:03, Nathaniel Smith wrote: > > > In particular I hesitate a little bit to just drop in everything from > > > PEP 426 and friends, because

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Can you clarify the relationship to PEP426 metadata? There's no standard for metadata in here other than what's required to run a build hook. Does that imply you would have each build tool enforce their own convention for where metadata is found? On Thu, Oct 1, 2015 at 9:53 PM, Nathaniel Smith

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 2, 2015 at 8:38:45 AM, David Cournapeau (courn...@gmail.com) wrote: > > A major feature of the proposal is to allow alternative build/packaging > tools. > > If that proposal is not acceptable in its current form, how would you > envision interoperability between pip and new systems.

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 2, 2015 at 12:58 PM, Donald Stufft wrote: > On October 2, 2015 at 12:54:03 AM, Nathaniel Smith (n...@pobox.com) wrote: > > > We realized that actually as far as we could tell, it wouldn't > > be that > > hard at this point to clean up how sdists work so that it

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On October 2, 2015 at 12:54:03 AM, Nathaniel Smith (n...@pobox.com) wrote: > > We realized that actually as far as we could tell, it wouldn't > be that > hard at this point to clean up how sdists work so that it would be > possible to migrate away from distutils. So we wrote up a little >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Thank you for your work on this. We have to kill distutils to make progress in packaging. On Fri, Oct 2, 2015 at 10:12 AM Daniel Holth wrote: > One way to do sdist 2.0 would be to have the package-1.0.dist-info > directory in there (most sdists contain setuptools metadata) and

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

One way to do sdist 2.0 would be to have the package-1.0.dist-info directory in there (most sdists contain setuptools metadata) and to have a flag static-metadata=1 in setup.cfg asserting that setup.py [if present] does not alter the list of dependencies. In the old MEBS design the package could

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

> > > So downstream distributors can download an sdist - or even a tarball of a > VCS tag, if they're being strict about it - build wheels from that using > the config in this proposal, and then transform the wheels into their own > package format. > this has wheel itself being the

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 2 October 2015 at 12:58, Donald Stufft wrote: > The first thing that immediately stood out to me, is that it's recommending > that downstream redistributors like Debian, Fedora, etc utilize Wheels > instead > of the sdist to build their packages from. However, that is not

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, 2 Oct 2015 at 05:08 Donald Stufft wrote: > On October 2, 2015 at 12:54:03 AM, Nathaniel Smith (n...@pobox.com) wrote: > > > We realized that actually as far as we could tell, it wouldn't > > be that > > hard at this point to clean up how sdists work so that it would be

  1   2   >