By the way, there are some cleanups under https://github.com/andreaferretti/factor-work
But still, I am leaving https://github.com/andreaferretti/factor-packages untouched, so that it works as described in the previous email, in case someone wants to try it. Moreover, notice that https://github.com/andreaferretti/factor-work also contains the two vocabularies that are fetched in the example, so cloning factor-work and then trying the example will not work as expected. 2014-12-17 17:57 GMT+01:00 Alex Vondrak <ajvond...@gmail.com>: > Excited to see where this goes! I like the DSL - reminds me of how it feels > to use [Bundler](http://bundler.io/), where the language for dependency > management is the same as the language you're coding in. (Can you tell my > day job is in Ruby?) > > I don't really have anything to add - I can't seem to find the time to touch > Factor these days, and I shy away from the Big Decisions when it comes to > package management (I understand it's a deceptively subtle problem). But I > enjoyed reading about your work, and wanted you to know. :) > > On Wed, Dec 17, 2014 at 8:28 AM, John Benediktsson <mrj...@gmail.com> wrote: >> >> Hi Andrea, >> >> I want to look through this and give you a more full response, looks like >> a pretty good start. Thank you! >> >> One of the benefits to the "one big tree" that we have right now is that >> we guarantee to update your code as the standard library changes or >> improves. This prevents bitrot and allows for some flexibility in changing >> common words. That matters less over time as the standard library becomes >> more mature, but has been useful at times. We've wanted ``extra/`` to be >> very very easy to contribute to as a way of supporting new contributors and >> then involving them as we keep an eye on their code. Obviously there are >> drawbacks to this approach too... >> >> Of course people can have their own repositories, and we should support >> them as best we can (like support for adding vocab roots or through a >> package manager), but I always want to encourage contributions when it makes >> sense for everyone. >> >> Having something simple that encourages re-use of code is pretty great, we >> could probably share our testing infrastructure to support easy continuous >> integration for a project developed this way. >> >> More to come later when I have time. >> >> Best, >> John. >> >> >> >> On Wed, Dec 17, 2014 at 6:20 AM, Andrea Ferretti >> <ferrettiand...@gmail.com> wrote: >>> >>> Hi, following this [small >>> discussion](https://news.ycombinator.com/item?id=8750720) I thought I >>> might give a try at designing a simple package manager. >>> >>> It is inspired by [Metacello](https://code.google.com/p/metacello/) >>> but delegates to existing source control management software such as >>> git the actual handling of repositories, similar to >>> [Bower](http://bower.io/). >>> >>> You can find the stub of a package manager >>> [here](https://github.com/andreaferretti/factor-packages) (keep in >>> mind: this is just the work of a day, and I am still a beginner). >>> >>> Outline >>> ------- >>> >>> The central concept is that of a *project*. A project has a name and a >>> version, and contains some vocabularies. It can also depend on other >>> projects. There are syntax words to define the structure of a project, >>> which currently look like this (for a hypothetical project): >>> >>> >>> USING: packages.syntax >>> IN: example-project >>> >>> PROJECT: example >>> >>> VERSION: 0.2.0-alpha >>> >>> VOCAB: example.thrift >>> >>> VOCAB: example.main >>> >>> DEPENDENCY: thrift >>> GITHUB{ "factor" "thrift" "0.2.5" } >>> >>> One can then do the following in the listener >>> >>> IN: scratchpad >>> USE: packages.projects >>> "example-project" activate >>> >>> This clones the repository for each of the dependencies in a subfolder >>> of "resource:cache" and switches to the given version. It is expected >>> that each dependency contains a toplevel file `project.factor` as >>> above. Then, transitive dependencies are recursively fetched. >>> >>> After fetching all dependencies, the vocabulary roots are adjusted, >>> and finally all vocabularies mentioned in the project or in a >>> dependency are `require`d. >>> >>> If you import the package manager in your work folder, you can see a >>> [simple >>> example](https://github.com/andreaferretti/factor-packages/blob/master/packages/example/example.factor) >>> in action. Just do >>> >>> IN: scratchpad >>> USE: packages.projects >>> "packages.example" activate >>> >>> You will then be able to use, say, the `monoid` dependency, like this >>> >>> IN: scratchpad >>> 3 5 |+| >>> >>> I would like to get feedback on the above design, so as to understand >>> if it is worth the effort to develop this into something actually >>> usable. While very simplistic, I think this approach has a couple of >>> advantages: >>> >>> * it does not require any change to the Factor vocabulary system >>> * by exploiting existing SCM (git and hg are currently supported, but >>> it would be easy to add more) one can avoid the need to setup a >>> repository and to develop a custom protocol. >>> >>> Issues >>> ------ >>> >>> If the above looks any good, there are a number of things one can >>> improve. All of those seem easy enough, they just requires some time. >>> >>> * support other SCM (svn, darcs, bazaar, ...) >>> * improve the DSL (for instance, should we have VOCABS: ?) >>> * add support for publishing, as well as consuming packages. This >>> would allow to do something like `"mypackage" publish` and >>> - copy the vocabularies in the cache under the appropriate subfolder >>> - copy the definition file as project.factor >>> - commit the result >>> - tag with the declared version >>> - possibly sync it with online repositories >>> * add error reporting >>> * add standard stuff: tests, docs... >>> * general cleanup and refactoring >>> * GUI tools to support the workflows >>> >>> There are also some issues one may want to consider: >>> >>> * Are there any performance problems in supporting a possibly large >>> set of vocab-roots? (I think not, I see there is a cache for this) >>> * What about the files `project.factor`? Currently they do not follow >>> the standard conventions about file placement. Should I change the >>> directory structure to put them in valid places? >>> * In every package manager there is the issue of transitive >>> dependencies that are included multiple times with different versions. >>> As of now, the result of the above algorithm is that the last version >>> mentioned wins. What could be a better policy? One issue here is that >>> other package managers - Maven, for instance - fetch the specification >>> (in the form of pom.xml) separately from the artifact itself. This >>> allows them to have the complete picture *before* starting to download >>> dependencies, hence apply any policy they choose. The way I have >>> handled it, project.factor files coexist in the same repository as the >>> vocabularies themselves, which complicates things a bit (I have to >>> checkout the repositories to even look at dependencies, but later I >>> may change idea about which versions to use). >>> * If a package manager was used, what would be the impact on the >>> Factor ecosystem? After all, the current model of putting everything >>> in the main repository has some advantages: >>> - it is easier to discover libraries >>> - we avoid redundancy, which at this scale is important (no need for >>> anyone to make another json library, as it is already there) >>> Both points could be partially mitigated having a set of officially >>> endorsed packages, which are one click away in the listener. On the >>> other hand, it will not be feasible forever to have everything in the >>> main repository, and in particular this presents issues when >>> developing libraries which are tied to external projects whose >>> versions (and possibly protocols) do change (MySQL, Redis, Kafka, >>> ZeroMQ and so on). >>> >>> ================= >>> >>> Well, this mail was long enough! Let me know what you think about it :-) >>> >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Factor-talk mailing list >>> Factor-talk@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/factor-talk >> >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
