Hi Andrea! > 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.
I understand what you're getting at. I think in that scenario Mr. A should rename his library to acme-lib2 then it would be trivial to have both variants of the library installed at the same time. > 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. You could make a shim library. One frontend that using Factors multiple dispatch can multiplex between backends. That is how both the assembler is implemented, with backends for x86.64, x86.32 and ppc, and the UI system with backends for GTK, Windows and OS X. >> 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 Thanks, now I got it to work! >> * 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. My view on syntax words is that they should be discouraged as much as possible. Often they are "locally good, globally bad". What I mean by that is that they improve the appearance of the code in one area (such as package management) but the more syntax words you have, the harder Factor code becomes to understand. >> 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 Can't you make the convention that the bottom -pkg.factor file is the package metadata file? So for factor-package-manager you would have: /packages/fs/fs.factor /packages/packages.factor /packages/packages-pkg.factor /packages/projects/projects.factor /packages/publish/publish.factor /packages/scm/scm.factor /packages/syntax/syntax.factor Since the directory is packages, the package manager knows the metadata file is at /packages/packages-pkg.factor and that the vocabs making part of the package are: { packages packages.fs packages.projects packages.publish packages.scm packages.syntax }. >> * 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. I don't think there is a misunderstanding, if there is, then it's about what is appropriate for Factor at this current point in time. In particular, I'm worrying that multiple version installs is premature. For example, suppose you run a web server in a thread in the background that depends on package foo==0.8.2 and in the foreground, you play Tetris which depends on foo==0.9.0. Then you type "save" to save the image. What version of foo will be written to the image? In JVM-land that is a non issue because why on earth would you play Tetris in the same process that runs your web server? But with Factor I have one process in which I do everything, repl work, hack the compiler, syntax highlighting using FUEL, GUI programming etc. It lives on forever which I like a lot and I don't want to start a new VM for each task I'm on. A solution to the above might be something like Python's virtualenvs. But I have no idea. Anyway, if you do not target multi-version package installs, then you wouldn't need one vocab root per package, so why not start there? Suppose something as simple as: IN: scratchpad "https://github.com/andreaferretti/factor-options"; install-package ... chunka chunka .. installed! IN: scratchpad installed-packages get-global . { ... "options" ... } IN: scratchpad USE: options ... IN: scratchpad "options" remove-package ... chunka chunka .. removed! IN: scratchpad USE: options 1: USE: options ^ Vocabulary does not exist name "options" Type :help for debugging help. -- mvh/best regards Björn Lindqvist ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
