On Mon, Mar 29, 2010 at 10:37 PM, Floris Bruynooghe <floris.bruynoo...@gmail.com> wrote: > Hi > > On Thu, Mar 25, 2010 at 11:20:41AM +0100, Tarek Ziadé wrote: >> I've sent a mail after Pycon to request some comments on the work we >> have done during Pycon but I had no feedback at all :) >> >> http://mail.python.org/pipermail/distutils-sig/2010-March/015684.html >> >> I realize that this piece of work is quite dense, and hard to follow. >> >> (As a reminder the draft is here: >> http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst) > > This work calls for a systemwide sysconfig.cfg file which maps the > categories onto system locations. I notice the example one contains > sections for "posix" and "posix_home" (among others), presumably the > "posix_home" one is for when using "setup.py --home".
Yes, >But what about > the user site-packages directory (setup.py --user)? Would it make > sense to have a sysconfig.cfg (or equivalent) file in the user > site-packages too? What about having a user section in sysconfig.cfg ? > > On a tangent it seems to like --home should be deprecated in favour of > --user. Any toughts on this? Why deprecating --home ? It's a target for unix-only systems, but not specific to a user > > > As for the 1st point of the open issues - what about pkgutil.open() > without having to use a "setup.py develop"; here a half baked idea: If > the sys.path entry from which the current module came from does not > contain the setup.cfg metadata required can pkgutil.open() not assume > that it's a non-installed package/module and simply use the relative > path to find the resource? Altough I can still see this getting messy > with non-inplace builds of extension modules. I think it's a bit what we've try to do: pkgutil.open() works with paths in the development tree, relative to setup.py/cfg. If its' not what you mean, can you provide examples ? > > > Lastly has toydist's "toysetup.info" from David Cournapeau been > considered in the discussions on setup.cfg for distutils2? It's a > pretty nice format and it actually has an implementation too. No. I havn't looked at it yet, I think its pretty new (like, a few months maybe?) > I do > think there is value in that format to superseed the > setup.py/setup.cfg combination (there is the problem of setup.cfg now > becoming both a config file for the developer as well as a formal > description for the package distribution). Currently it seems a lot > more verbose for tagging files under categories compared to the > proposed setup.cfg, but that might not be set in stone and I hope > David will be happy to incorporate reasonable proposals if this is > preceived to be a problem. If David could participate to this discussion and present his ideas on this, that would be great. We could compare both syntaxes and try to build the best one. > > > Regards > Floris > > PS: Thanks for the work of writing up the PyCon packaging sprint! For the wiki.rst, that's mainly other people from the sprint group that did this summary ;) So +1 in the thanks -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig