Hi Andrea,
I think it's a great idea! And I love that you built something we can
start using and thinking about. My preference would be to keep it simple
and iterate on it as often as you can. Start solving problems and when you
come across some new problem that needs solving, well then solve that too.
Would it make sense at some point for the package manager to be in the main
distribution?
These weeks are a little busy for me with the holidays, so I was hoping to
look at this more first week of January.
Best,
John.
On Mon, Dec 22, 2014 at 8:40 AM, Andrea Ferretti <ferrettiand...@gmail.com>
wrote:
>
> I would like to spark a little discussion: is a package manager seen
> as something useful? Is it needed at this time? Could it be reasonably
> implemented using symlinks? (Kind of what Npm does).
>
> I do not want to push something if the community does not feel the
> need for it - at least at the moment. At the same time, I would like
> very much to help if I can.
>
> I took the freedom to stub a package manager because for me it was one
> of the main issue in really adopting Factor, but others may feel
> otherwise
>
> 2014-12-19 10:52 GMT+01:00 Andrea Ferretti <ferrettiand...@gmail.com>:
> > 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
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
