Hi Björn, great points! Let me try to comment on them. 2014-12-19 5:14 GMT+01:00 Björn Lindqvist <bjou...@gmail.com>: > Great work Andrea! > > Factor needs a package management system eventually. Programmers have > this strange infatuation with packages and unless the language offers > it, it's just not taken seriously. Maybe because people are customed > to the language core being almost closed and the bar uber high for > contributions so people feel they need to release their own packages > to contribute. > > I think Factor's community is more open than that and John and Doug > are amazingly responsive on the bug tracker. So if you have any > worthwhile code to contribute, just make a pull request and it will be > merged quickly. Then you'll get code maintenance for free in case the > language changes and your test suite is setup to run nightly which > catches bugs.
I am sure that John and Doug are doing a fantastic work! The use case I imagined a package manager would be useful, though, is slightly different. First, in a typical corporate setting, there may be a need to mantain different versions of a library at a time. Upgrading all clients of the library may not be feasible because of manpower. It often happens that Mr. A writes a first version of a library acme-lib which is used by Mr B to write acme-webapp,. Then Mr. A releases a much improved version of acme-lib, and everyone at acme uses it, but unfortunately the API has changed a lot. acme-webapp is now in manteinance mode, and Mr. B just left to found his own startup. There should be a way to keep working on acme-webapp - say to fix vulnerabilities - without requiring a complex refactoring just to move to the new version of acme-lib. In other words, there should be two co-existent versions of acme-lib, and clients should be free to decide which one to use and upgrade at their own pace. Second, and possibly more important, versions do exist externally. For instance, I was thinking about writing a library to talk with the Kafka messaging system. The binary protocol of Kafka has changed between versions 0.7 and 0.8. If I had implemented a Kafka library for Factor before 0.8 came out, I may now have the need to upgrade it to support 0.8, without losing the possibility to connect to 0.7 clusters. > > So I tried to get your package manager to work, but something goes wrong: > > USE: packages.example > "example-project" activate > Added "packages.projects" vocabulary to search path > More than one file found for vocabulary: example-project > > Type :help for debugging help. > If you are using the version in https://github.com/andreaferretti/factor-packages - which I left unchanged so that people can try it without issues, it should be USE: packages.projects "packages.example" activate There may be an issue with the error message, but error reporting is just not there yet. Let me know if it works for you > Maybe the code is in flux? Anyway, here are some random thoughts about > your implementation: > > * You can't have one voacb root per package. If you run "threads." in > the listener, you'll see that there is one thread for each of the > three roots. They monitor that directory tree and reloads vocabs > that change automatically. See > http://docs.factorcode.org/content/article-vocabs.refresh.html So > yes, there are performance problems. This is a serious issue, and I think it is the most important point. On Mac and Linux, it would be easy to just download the packages themselves and then symlinking them into work, instead of altering the vocab roots. I am not sure if anything like that can be done on Windows, though (I haven't used Windows for 8 years now - maybe they finally have symlinks?) > > * So for example, to install your monoid package, I run: > > $ git clone https://github.com/andreaferretti/factor-monoid > $ cp -r factor-monoid/monoid /opt/factor64/lib/factor/extra > > (Thats where my resources:extra is) And in the listener: > > IN: scratchpad USE: monoid > IN: scratchpad 3 3 |+| . > 6 > > No need to restart Factor or any other setup to get it > going. Suppose then you released a new version of monoid, I would > copy it to /opt/factor64/lib/factor/extra and then simply run: > > IN: scratchpad refresh-all > Loading resource:extra/monoid/monoid.factor > > Factor would then recompile your monoid vocab and not only that, all > vocabs I have loaded that uses monoid would automatically be > recompiled too. > > Uninstallation is a sore point though and that's where I think a > package managerwould really shine. This works just because monoid exists in a single version and does not have any dependency. Otherwise, you would have to download all the dependencies too, and make sure to use versions that work well together. Moreover, this is not easily reproducible. Say you do something that uses monoid and you want to pass it to a coworker: you will have to instruct them to follow the same steps. There is no single point in your project that lists what you depend on, and makes sure the project can be used somewhere else. Let me make a small comparison with Scala, which is what I use at work. I could make an application that depends on Akka to do concurrency, talks to external systems via ZeroMQ, and needs to manage dates. All I need is to write a file called build.sbt and put these lines in it libraryDependencies += Seq( "com.typesafe.akka" %% "akka-actor" % "2.3.8", "org.zeromq" % "jeromq" % "0.3.4", "com.github.nscala-time" %% "nscala-time" % "1.6.0" ) and now everyone that wants to build my application can download it and run `sbt compile`. sbt (the scala package manager) will take care of downloading all needed depenencies, including transitive ones such as "com.typesafe" % "config" % "1.2.1", without the need to manually track this. > > * Maybe we can repurpouse resource:extra as the package installation > url? In a way it already is. Or we could add a specific > resource:packages root. I am using a folder called resource:cache for this. The reason this is not a vocab root, but instead its subfolders are, is that this allows selectively enabling and disabling single dependencies. Otherwise, one would end up having everything ever downloaded in the classpath, and this would make dependency tracking more complicated. The approach I have taken is that when you activate a package, only its (transitive) dependencies are added to the vocab roots, and everything else is removed from the roots. This should reasonably ensure that all you depend on is correctly tracked. If one had the whole package cache as a vocab root, then it may happen that one depends on something that is in the cache but is not listed as a dependency. > > * I like that the configuration is Factor code, but I think you went > to syntax happy. :) A simple assoc would suffice: > > { > { project "example-project" } > { url "https://github.com/andreaferretti/factor-example.git"; } > { version "0.1.0" } > { dependencies { > "https://github.com/andreaferretti/factor-packages.git"; > "https://github.com/andreaferretti/factor-options.git"; > } } > } Yes, I have slightly simplfied the syntax, but it may make sense to remove it altogether. I wanted to mimic the module system, which has IN:, USE:, USING: and so on. > > Also the standard convention is to have metadata inside the > vocabulary's own directory. So why not have it in say > monoid/monoid-pkg.factor? It would be symmetrical with the > -docs.factor and -tests.factor suffixes. The issue here is that a package may reasonably consist of more than one vocabulary. For instance, see the definition of the package manager itself, which is a project containing 6 vocabularies: https://github.com/andreaferretti/factor-package-manager/blob/master/project.factor > > * You might also want to look into Factor's application deployment > system: http://docs.factorcode.org/content/article-tools.deploy.html > because deployment has many similarities with making packages. Also > see the summary.txt, authors.txt, deploy.factor and tags.txt > files. Possibly they could all be merged into one > vocabname-meta.factor file? Thank you, I will have a look at it > > * I realised you've spent a lot of thought thinking about how > dependencies and especially transitive dependencies should > work. Personally, I think it's way, way, to soon to think about that > and a package manager that just handled the packaging and not any > deps would still be really useful. I think there may be a mistunderstanding here, but for me the whole point of a package manager is to handle dependencies recursively. I think we may be using the word in a different sense. What I am trying to design is not a package manager in the sense of a tool that produces .deb or .rpm files, but instead something which lets you assign names and versions to a package - which is a collection of vocabularies - and manage dependencies among packages, which means automating the step of downloading everything that is required and making it available to be imported in your programs. It was meant to be the equivalent of tools such as sbt, maven, leiningen, npm, metacello. Given your remark, I suspect you have something different in mind. > > * Feel free to ignore all my points above. :) It's ofcourse better if > a package manager is created than that bikeshedding prevents it from > ever happening. > > > > -- > mvh/best regards Björn Lindqvist Thank you very much for your feedback! Given the points above - especially the one about having many vocab roots - I will pause it for a while, until it is clear what would be a good way to design it. Best, Andrea > > ------------------------------------------------------------------------------ > 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
