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
