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