On Tue, Sep 1, 2015 at 6:58 PM, Alexis King <lexi.lam...@gmail.com> wrote: > The frustrating thing about this problem is that it is a problem that seems > to be fundamentally *solved*. PLaneT didn’t do it quite right, it’s true, but > the current package system doesn’t, either. In fact, in a number of ways, the > new system is catastrophically worse than the old one (it doesn’t scale). > > I’ve ranted about this plenty already, but most people seem unconvinced about > why this is such a massive problem. I maintain that it is. With a little bit > more knowledge on this topic, let me express precisely why the current system > does not work. > > In this conversation, two people touched upon points that I think are > important. > > First, from Neil: >> My super-strongly preferred engineering notion: backward-compatibility of a >> package refers to the *documented* behavior of the package, not to actual >> behavior. > > Second, from Jack: >> The biggest problem thus far with this workflow is that if a package `foo` >> says "I require version 2.0 of package X", the package catalog can only give >> you the most recent version of package X. This isn't a major issue if >> package X is well-behaved regarding backwards compatibility, but as these >> are social rules and not technical ones, outliers will exist. > > These are both incredibly flawed. They might work fine in a tiny little > academic environment, but in the real world, this is almost outlandish for a > few reasons: > > 1. Things that are “just bugfixes” will inevitably break things every once > in a while. > 2. If a library has a bug, sometimes the only way to deal with it is to > hack around the bug. When the bug is fixed, the hack might break. > Broken code! > 3. Asking people to make a new package for every breaking change they > introduce (1) introduces a large barrier to package developers and (2) > will lead to a massively cluttered set of packages with no semantic > clarity about the differences. Packages foo12 and foo13 might have tiny > incompatibilities, but foo13 and foo14 might be whole rewrites.
Another lesson is that developers of code that lots of people rely on should seriously reconsider when they want to introduce breaking changes. And for authors of code that very few people rely on, they could explicitly work with them to help update their code. These two patterns are what the long-term Racket developers have pursued. > This can be solved with tooling, fortunately. However, it does mean that, > under the current model, every new version of a package will need to be a > distinct “package” under the current system’s definition of “package”. > > So what’s the right way to do it? > > 1. Use semantic versioning to version packages and to resolve > dependencies. This works, but it still has the social problem, so… > 2. Introduce a dependency “lockfile” the way Ruby’s Bundler tool does. > This means that dependencies won’t change unless a user explicitly > updates them, but updating to a new version is still painless because > semantic versioning makes it clear. > 3. Make this the only user-facing interface. Either scrap the current > system or make it an internal component of a larger system. I've said since the beginning that I think the package system supports being a component in a PLaneT-like meta-package system. I think you should work on it if you see it as a crucial problem. Let me know how I can help! > I’ve actually taken some small stabs at implementing something like this, but > it’s a nontrivial project, especially since the current package server’s API > seems to be undocumented (I’m referring to the API the JS uses, not the > interface raco uses). Plus I’d be on my own, and so far people don’t seem to > care much about fixing this. Perhaps I’m wrong and it’s not as big of a > problem as I think. > Regarding the API that the JS uses, the server implementation is less than 500 lines and is open-source: https://github.com/racket/pkg-index/blob/master/official/dynamic.rkt If you look at line 428, you'll see the 11 API calls: [("jsonp" "authenticate") jsonp/authenticate] [("jsonp" "update") jsonp/update] [("jsonp" "package" "del") jsonp/package/del] [("jsonp" "package" "modify") jsonp/package/modify] [("jsonp" "package" "version" "add") jsonp/package/version/add] [("jsonp" "package" "version" "del") jsonp/package/version/del] [("jsonp" "package" "tag" "add") jsonp/package/tag/add] [("jsonp" "package" "tag" "del") jsonp/package/tag/del] [("jsonp" "package" "author" "add") jsonp/package/author/add] [("jsonp" "package" "author" "del") jsonp/package/author/del] [("jsonp" "package" "curate") jsonp/package/curate] Each implementation starts with a simple hash table naming the arguments: (jsonp/package/version/add ['pkg pkg] ['version version] ['source source]) If there were another client, I would be happy to accept a patch documenting and committing to the API. Jay > Alexis > > (As an aside, the ability to introduce breaking changes into an API without > fear of breaking everyone’s code is incredibly powerful for a package > maintainer. It’s mostly why the iteration speed in JS-land can be so > blindingly fast, but everyone still hangs together. There are problems with > that example, specifically, but working on Racket packages feels like walking > on eggshells in comparison.) > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-dev@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/60656584-93BE-412D-B46E-64A26943B78E%40gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAJYbDanyFQTrPJpRXm%2BF2Xrk%2BqsUJRaZUewLAHXreX0po8TaeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
