On Mar 30, 2015, at 8:33 PM, Alex Clark <aclark@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@gmail.com> wrote:
On 30 March 2015 at 16:45, Donald Stufft <donald@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