> On Mar 30, 2015, at 8:33 PM, Alex Clark <acl...@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.mo...@gmail.com> wrote: >>> >>> On 30 March 2015 at 16:45, Donald Stufft <don...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
