[Distutils] it's happened - wheels without sdists (flit)

[Donald Stufft]

> On Mar 30, 2015, at 8:33 PM, Alex Clark <aclark at aclark.net> wrote:
> 
> On 3/30/15 11:56 AM, Donald Stufft wrote:
>> 
>>> On Mar 30, 2015, at 11:52 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> 
>>> On 30 March 2015 at 16:45, Donald Stufft <donald at stufft.io> wrote:
>>>> Well, parts of it are turing complete, since it pulls the version number
>>>> out of the module itself and that’s just Python too.
>>> 
>>> Sorry, I wasn't specifically looking at flit there. But I'm in the
>>> camp that says just put the version in your ini file and in your
>>> module, and don't worry that you have it in 2 places. If managing
>>> version numbers is the biggest showstopper in moving to declarative
>>> metadata, then we've won :-)
>>> 
>>> Paul
>> 
>> Honestly, I don’t think that setup.py as a development interface is that
>> bad. It gets really bad when we start sticking it inside of a sdist and
>> using that as part of the installation metadata.
>> 
>> It’s not unusual for me to want (or need) to do something a little bit
>> different in a project, or something that the original authors didn’t
>> quite intend to do. This is perfectly valid and fine inside of a file
>> that only ever gets executed on a developer machine. However it *needs*
>> to be “compiled” down to a static file when creating a sdist.
> 
> 
> Right, that is my understanding: setup.py is fine except when it is executed on installation.
> 
> But I think there is a slight cognitive advantage to setup.ini vs. setup.py. You can never execute an ini file, even in development. So the same file can (somehow) be used in development and production without "compiling down" first. In other words: maybe switching to ini is the right thing to do long term.
> 
> However, the practicality of doing so may be so small (due to disutils/setuptools baggage and/or inability to overcome setup.py momentum) that "compiling down" (setup.py) becomes a more attractive first step, at least.
> 

I think trying to use the same file is an attractive nuisance. Separating them lets you do a lot more for developer convenience without hurting the ability of the installation side of things. For instance, it’s somewhat common to want to import the module in order to pull the version out of it. That’s not something we’d want to do outside of the developer side of things, but it’s something that’s completely reasonable to do in the developer toolchain (either implicitly as in flit, or explicitly as in setup.py).

IOW, splitting these into the “developer side” tooling and the “format that automated installers consume” lets you define both of them to be the best at what they are doing instead of trying to put something together that satisfies two competing use cases.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150330/12c4c486/attachment.sig>