[Distutils] Builders vs Installers

[Daniel Holth]

On Wed, Mar 27, 2013 at 1:30 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On Mar 27, 2013, at 1:12 PM, PJ Eby <pje at telecommunity.com> wrote:
>
>> On Wed, Mar 27, 2013 at 8:02 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>>> To those people who would balk at editing JSON by hand - who's asking you
>>> to? Why not just get the data into an appropriate dict, using any tools you
>>> like, and then serialise it to JSON?
>>
>> The challenge here is again the distinction between raw source and
>> sdist, and the interaction with revision control.  Either there has to
>> be some way to tell MEBS (i.e. the overall build system) what tool
>> you're using to generate that JSON, or you have to check a generated
>> file into revision control, and make sure you've updated it.  (Which
>> is error prone, even if you don't mind checking generated files into
>> revision control.)
>>
>> This strongly suggests there needs to be *some* human-editable way to
>> at *least* specify what tool you're using to generate the JSON with.
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
> I don't actually think packaging needs to solve this. But there are a number of solutions that come to mind (mostly either expecting a standard command ala setup.py develop to work).
>
> If I want to install a development version of say libsodium (just an example C lib) I download it and run ./autogen.sh && make make install but once it's packaged I can install it using the packaging tools.
>
> So this issue is really sort of parallel to builders, archivers and even the JSON and it comes down to how does an unpackaged directory of code (the VCS checkout portion isn't really that important here) signal to an installer how to install a development version of it. Personally I think a common entrypoint (ala make install) is the way forward for this. When you leave the realm of package formats (ala sdist, wheel, etc) you start needing to get much more freeform.

It does get a little murky.

nothing the file in a source checkout
PKG-INFO the file in an sdist
PKG-INFO the re-generated file
PKG-INFO the installed file

(we will probably call it metadata.json soon but the confusion is the same).

I think it might make sense to expect only a stub PKG-INFO[.in] at the
root of a VCS checkout, have a 100% generated and hopefully
trustworthy .dist-info directory in an sdist, and don't bother
regenerating the root PKG-INFO.