On Thu, Aug 23, 2012 at 04:05:32PM -0400, Joe Groff wrote: > Doug and I were discussing an overhaul of Factor's vocabulary system > to make it easier to work with source code outside of the Factor > repository and to enable gem or npm-style package management down the > line. I've sketched out a proposed design and pasted it to a Gist:
I'm no expert in these matters, but it worries me a little that you mention Ruby Gems as one potential inspiration: I know that (for example) Debian doesn't package many Ruby libraries because the Gem system interacts poorly with a system-wide package-manager. Other languages like Perl and Python seem to have tons of libraries packaged in Debian, so they might be better models. On the other hand, the Python packaging system has been redesigned for Python 3.3, and if I recall correctly one of the big features is "make it easier to build system packages (.deb, .rpm) from Python packages by putting all the metadata in a static file", and it seems your proposal's "package.factorpackage" is exactly that, so maybe that'd be fine. Having a "image.factorimage" file in a package might make life a bit complicated - aren't Factor images platform specific? What happens if somebody "launches the Factor VM from inside the package directory" but the image is for a different architecture? ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
