I definitely have no problem with allowing meta files to be named after components, nor the notion of finer granularity within them. I would suggest ".meta.json"/".meta.xml" or simply ".meta" as the extension, though, as these retain the information about the semantics of the content and not just the (largely unimportant) syntax of the content.
BTW, note that I said that the destiny branch was BETTER with regards to make dist, not necessarily that it was good. :) Many of the issues you raise are still valid there. -- Murphy On Sat, 2010-08-07 at 09:25 +0900, Romain Lenglet wrote: > Hi James, > > Thanks for your comments. My replies are inline below. > > On 2010-08-07 02:17, James "Murphy" McCauley wrote: > > It mostly stands as "it doesn't seem worth it to get into it". We were > > interested in improving modularity some (and the idea of replacing the > > build system wholesale did come up), but it became clear that it was going > > to be a lot of effort to do something that wasn't necessary to achieve our > > more immediate goal for anyway. > > > > That goal, BTW, is to move the "standard" for third-party component > > development from building them inside the tree to building them outside the > > tree. I think this simplifies things somewhat, but another (open) question > > is: are we willing to throw out the idea of doing static builds? If we're > > not worried about that, I think that's another simplification. > > > > > > Some thoughts: > > > > I'm worried about making changes that are going to be Debian-specific > > (e.g., relying on update-python-modules). > > I will not make any Debian-specific changes. Using Debian's > dh_pysupport, make install only needs to copy the Python source files > into /usr/share/python-*/site-packages/ (the standard location), and > dh_pysupport will copy those files into > /usr/share/pyshared/site-packages/ at package generation time and do all > the Debian-specific stuff. > > But right now, not installing the Python sources and keeping only > compiled Python modules in a non-standard location doesn't work for > Debian packaging. > > > I'm not sure I agree re: installing meta.xml/meta.json to a centralized > > location. This makes sense for a world in which the norm is for people to > > install a NOX package and a bunch of component packages, maybe. But I > > think it makes less sense for people doing research and experiments with > > NOX. I think "encapsulating" a component in a directory works pretty well. > > At the minimum, it seems like we'd need a way to specify additional > > directories of metafiles on the commandline or something like that. > > The problem with the current system is that NOX requires files to be > named only 'meta.xml', i.e. if one wants to have two components in the > same Python package, this requires to specify them in the same meta.xml > file which prevents packaging the two components separately, or to > create subdirectories just to be able to have multiple meta.xml which is > cumbersome. > > I was thinking of something like the /etc/*.d/ directories (e.g. > /etc/cron.d/). More specifically I propose to: > - accept any files named /usr/share/nox/**/*.xml, instead of requiring > them to be called meta.xml; > - look for files in additional directories by default, e.g. > /usr/local/share/nox/**/*.xml. > > Since the component namespace is flat, a good way to handle collisions > would be to recommend users to name their *.xml files after the names of > the components they specify: switch.xml, topology.xml, etc. > > > Besides that, this sounds really good, and I think we could put a lot of > > these improvements into the destiny branch (by the way, make dist in > > destiny is somewhat improved over master already in that it actually does > > at least sort of work). > > OK, I'll take a look at the destiny branch. > > Best regards, > -- > Romain Lenglet _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
