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
