Agreed that python is a fine language for build scripts.

On Wed, Mar 27, 2013 at 1:51 PM, Donald Stufft <don...@stufft.io> wrote:
>
> On Mar 27, 2013, at 1:41 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>
>> PJ Eby <pje <at> telecommunity.com> writes:
>>
>>> 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.
>>
>> There are no doubt many possible workflows, but one such is:
>>
>> metadata input files - any number, hand-edited, checked into source control
>> metadata merge tool - creates JSON metadata from input files
>> JSON metadata - produced by tool, so not checked in
>>
>> If the "merge tool" (which could be a simple Python script) is custom to a
>> project, it can be checked into source control in that project. If it is used
>> across multiple projects, it is maintained as a separate tool in its own repo
>> and, if you are just using it but not maintaining it, it becomes part of your
>> build toolset (like sphinx-build). Actually, the doc tools seem to be a good
>> analogy - create a useful format which is a pain to edit by hand (HTML that
>> looks nice in a browser) from some checked in sources which are reasonable
>> to edit by hand (.rst) + a merge tool (Sphinx).
>>
>> The merge tool seems similar in kind to the release.py script that many
>> projects have, which creates release distribution files, bumps version 
>> numbers,
>> registers and uploads to PyPI.
>>
>> Regards,
>>
>> Vinay Sajip
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
> I don't think the packaging formats should dictate the development flow at 
> all. .IN files and such all dictate how that should be. To me this is an 
> installer issue not a packaging issue and it's best solved in the installers. 
> Obviously there is some benefit to a "standard" way for installers to treat 
> these but I don't think it should be defined in terms of the packaging 
> formats. Hence my off the cuff suggestion of keeping setup.py develop, or 
> develop.py or some such script that express purpose is in use for development 
> checkouts, but that development checkouts should be discouraged unless you're 
> actively working on that project.
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to