On Wed, Mar 27, 2013 at 1:30 PM, Donald Stufft <don...@stufft.io> wrote: > > On Mar 27, 2013, at 1:12 PM, PJ Eby <p...@telecommunity.com> wrote: > >> On Wed, Mar 27, 2013 at 8:02 AM, Vinay Sajip <vinay_sa...@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@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
