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
