The idea of resource:work is great, but its location (inside the work/ directory of the Factor checkout itself) makes it really prone to an erroneous “git clean” if I’m not paying attention. Adding new vocabularies via .factor-roots or FACTOR_ROOTS is easy enough, but then requires I type out the full path in many situations (e.g. scaffold-vocab), which is also annoying, if for no other reason than my private vocabulary collection is in different places on different machines (different Unix users, different operating systems, etc.). What would be great is to say, “Treat /path/to/whatever as resource:whatever”. This doesn’t appear hard to add, but I’m wondering if there’s a reason we’re not already doing so.
As long as we’re on the topic: it looks relatively easy to extend out the
vocabulary system to support versions, so that, instead of doing
“whatever” require
you’d instead do
{ “whatever” “2.4” } require
which would allow you to selectively load a specific version of a vocabulary
into a specific Factor instance based on a slight tweak to the path (e.g.,
maybe whatever/ would become whatever/2.4/). I’m guessing we’ve not done this
because there’s concerns about this approach. What are they? Do we, like the
Go community, simply not want to support this? (My interest in this is
actually that doing so would be the first step towards allowing package
management, which really nicely dovetails with the above. Think having
resource:packages and then being able to just directly require a package you
want.)
Anyway, thoughts on either of the above?
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/
_______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
