---
# System prepended metadata

title: package versioning

---

# package versioning

A summary of the discusson 18-June 2020 on Racket slack.

The transcript is below so it isn't lost to slack.

Notes:

* Important issue for people running production servers (@badkins)
* *long term goal is simply to be able to specify a list of packages and their versions, and then be able to install all of those versioned packages with a raco pkg command. Ideally, this would be on a project/directory basis as different applications may have different needs.*(@badkins)
* It would be a large project requiring >1 FTE (Full Time Equivalent) (@notjack)
* "*enhancements to raco pkg that allow for*";
> 1. installing a specific version of a package, 
> 2. specifying a set of versions for each dependency package, and 
> 3. having a versioning scheme such as <major>.<minor>.<patch> where a bump in major number may break backward compatibility
(proposed by @badkins and agreed by @mflatt)

*  Summary of requirements (@samth)
> First, here's some overall thoughts. I think people with experience in other language package managers mostly miss the following things:
> 1. Being able to record the packages they depend on, and then check in something so they get the same packages when they rebuild in a different environment.
> 2. Having a per-project scope for packages, and being able to install different versions of a package for different projects.
> 3. Being able to specify specific versions of packages that you depend on, and have the package installation mechanism figure out appropriate versions of everything to install
> 4. Being able to have two different versions of a dependency appear in your dependency tree while everything keeps working.
> 
> There's also providing a smoother way of handling  backwards incompatible changes, but I think that's fundamentally separable
 
 
 
 
 ----
 ## Existing approaches
* [Racksnaps](https://racksnaps.defn.io/) (@bogdan)
* [Dependency Management in Racket Applications](https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html) (@Alex Harsanyi)
*  other approaches have been mentioned but I don't have specific links
 
 ## resources linked
 
* [creating your own package catalog](https://groups.google.com/d/msg/racket-users/4iI-SanIbzk/sGHYijLPAAAJ) (@jeapostrophe )
* ['adding proper versioning support to the existing package system would involve three distinct chunks of work'](https://www.reddit.com/r/Racket/comments/9rn5ms/raco_package_versioning/e8jx6ws/) (@lexi.lambda)
* [good summary of the state of the art]( https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527) (@notjack)
 
 
 ----
 
 ## transcript 
 ([slack link](https://racket.slack.com/archives/C06V96CKX/p1592513740189000))
As at 19-June-2020 9:35 am (times are British Summer time)
 
 badkins:racket-flat:  9:55 PM
I just looked through a thread on the mailing list about package versioning. If the accepted way to make backwards incompatible changes to a package is to change the package name, that's fine. I'm used to a major.minor.patch versioning of libraries/gems/packages, but whatever. However, I'm more concerned about the scenario where a package is updated and introduces a bug. I realize a few ways to handle this have been adopted by various people, but thus far, they've been unsatisfactory to me. @jeapostrophe mentioned an option of [creating your own package catalog](https://groups.google.com/d/msg/racket-users/4iI-SanIbzk/sGHYijLPAAAJ) which seems interesting. If you are using this method, would you mind commenting in a thread, and if you can point me to documentation, blog posts, etc. to help me get setup, that would be great.
> For this method to work for me, it would have to allow me to pin a particular version of a package after the package has been updated w/ a bug. In other words, if I have to have already pinned a package before it's updated with a bug, then this is a fail, but I think that's obvious.

1 reply
11 hours agoView thread

badkins:racket-flat:  10:01 PM
By the way, I really hope the long term goal is simply to be able to specify a list of packages and their versions, and then be able to install all of those versioned packages with a raco pkg command. Ideally, this would be on a project/directory basis as different applications may have different needs. Anything else seems ridiculous frankly.
10:03
Here's an example from the Ruby world:  https://bundler.io/

soegaard2  10:12 PM
@badkins One data point: https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html

badkins:racket-flat:  10:13 PM
Yes, while I appreciate that, it doesn't seem like the right approach to me. Bundler is far superior, and we need to get there.

badkins:racket-flat:  10:13 PM
We don't want a bunch of users creating their own ad-hoc solutions to this very common problem.


44 replies

> 44 replies
> 
> Sancho  11 hours ago
> How common is this problem? Meaning, how many racket users can't do what they want because of how the current package management system works? I've seen a few people bring this up, but have no idea of actual prevalence.
> 
> badkins:racket-flat:  11 hours ago
> Just out of curiosity, do you manage any production apps/servers?
> 
> Sancho  11 hours ago
> (i.e I've know of you, Sage, and Alex that have needed something more)
> 
> Sancho  11 hours ago
> Two. One racket based, one python based.
> 
> badkins:racket-flat:  11 hours ago
> Then you should be aware of the importance of configuration management, right? It's extremely important to be able to depend on a specific set of libraries at specific versions.
> 
> badkins:racket-flat:  11 hours ago
> I expect Python has a similar system to Ruby's Bundler.
> 
> Sancho  11 hours ago
> Ya, I know the argument. I was looking for info about how prevalent this issue is
> 
> badkins:racket-flat:  11 hours ago
> It's exactly as prevalent as there are people managing production apps/servers, right?
> 
> Sancho  11 hours ago
> I can make the argument that you and Sage and Alex make. But I haven't run into the issue myself.
> 
> badkins:racket-flat:  11 hours ago
> I think you're saying you haven't been bitten by it yet, but that's an extremely risky way to proceed.
> 
> Sancho  11 hours ago
> Ya
> 
> Sancho  11 hours ago
> I've been building a docker image and not deploying unless all the tests pass anew given any updated dependencies.
> 
> Sancho  11 hours ago
> So deployment is conditional on all things working with the latest versions of the dependencies.
> 
> badkins:racket-flat:  11 hours ago
> Sure. Envision this scenario. You install a set of packages, develop an application, and everything is fine. Then you setup a new server, install the same set of packages (some of which have been updated), and your tests fail. How do you get the set of packages on your development machine installed on the server?
> 
> badkins:racket-flat:  11 hours ago
> Or, you updated packages on your development machine, and tests fail - how do you roll back?
> 
> Sancho  11 hours ago
> I would deploy my docker image.
> 
> Sancho  11 hours ago
> But that's basically a checkpointing system, which may as well be considered an ad-hoc solution that you said we should be avoiding.
> 
> badkins:racket-flat:  11 hours ago
> Right. I'm not interested in Docker.
> 
> Sancho  11 hours ago
> But I don't need to be convinced that there are dev pipelines that would not work well with racket's package management system. I believe that. (edited) 
> 
> Bogdan  11 hours ago
> @badkins you might be interested in https://racksnaps.defn.io/
> :100:
> 1
> 
> 
> badkins:racket-flat:  11 hours ago
> How do you handle needing packages from different days?
> 
> Bogdan  11 hours ago
> You're forced to upgrade at that point.
> 
> badkins:racket-flat:  11 hours ago
> I don't think that will work then.
> 
> badkins:racket-flat:  11 hours ago
> I really don't get the resistance to a versioning system.
> 
> Sancho  11 hours ago
> You might be misinterpreting my question as resistance!
> 
> Sancho  11 hours ago
> Or my explanation about how I do things.
> 
> badkins:racket-flat:  11 hours ago
> Not at all - sorry for the confusion!  I was referring to pushback against versioning I've seen in various threads.
> 
> Sancho  11 hours ago
> Ah! Yes
> 
> Bogdan  11 hours ago
> I was pointing out racksnaps as a potential solution to:
> However, I'm more concerned about the scenario where a package is updated and introduces a bug.
But it's for sure not a general solution.
> 
> Bogdan  11 hours ago
> I also didn't get the sense that there was much resistance, just nuance and folks pitching in about their experience. I'm sure if someone builds versioning atop raco pkg and it ends up being a good system, then people will use it. (edited) 
> 
> badkins:racket-flat:  11 hours ago
> Maybe it was just defensiveness for not having a versioning system. I suppose the main pushback is for not allowing backward incompatible changes i.e. forcing a new package name. I'm less opinionated about that.
> 
> badkins:racket-flat:  11 hours ago
> @Bogdan to build something on top of raco pkg it seems that the current system would need to allow installing a specific version; otherwise, it seems like it might be an entirely new package system.

Bogdan  11 hours ago
You could have a system that generates a catalog on the fly that points to specific source versions of each package. The catalogs themselves are just mappings from package names to package sources (URLs).

> Bogdan  11 hours ago
> In this scenario the catalog is kind of the analog of a lockfile in other package managers.
> 
> badkins:racket-flat:  11 hours ago
> I guess I don't understand how to retrieve all the source versions for a package using the current package system.
> 
> badkins:racket-flat:  11 hours ago
> I suppose that's easy enough if they're using git; otherwise, I'm not sure.

> badkins:racket-flat:  11 hours ago
> For example, csv-reading

> Bogdan  11 hours ago
> The package server would have to be extended to support that kind of metadata and to be able to host all the versions of those packages (IMO, relying on Git is not a great idea). Or someone could create an alternative package server that supports those things. (edited) 

> badkins:racket-flat:  10 hours ago
> BTW @Bogdan thank you for racksnaps - I didn't mean to be so dismissive. I think it could be extremely useful even if I can't use it directly as intended. For example, if Neil updates csv-reading,  I would have no way of getting the previous version (if I didn't have it installed locally already), but I could grab it from racksnaps and put it into my custom catalog.

> Bogdan  10 hours ago
> No worries! Also, another way to address your original question could be to layer different snapshots.

> Bogdan  10 hours ago
> I hadn't thought about it much and I've never tried it, but conceptually it should work just fine.

> Bogdan  10 hours ago
> So say you want to rely on packages from 2016/06/14, but then a new package comes around on the 18th, you could just add the snap from the 18th as a secondary catalog.

> Bogdan  10 hours ago
> Of course, that doesn't work in many scenarios (eg. when you just want to upgrade a single package).
> 
> Bogdan  10 hours ago
> Generally, though, I've found that folks just don't make many breaking changes. When they do it's easy to upgrade and relying on daily snapshots prevents bugs from suddenly appearing.

Last reply 10 hours agoView thread

badkins:racket-flat:  10:41 PM
This is a related, but different question.  For one scenario, it would be sufficient for me to duplicate the package environment I have on my laptop to new production servers. I see that there is a raco pkg archive command - could that be used to accomplish this? I develop on MacOS, and I deploy on Linux.

ayman  11:22 PM
not sure where the right place to ask this question is but I was wondering if expand supports reading in a module that has unbound identifiers. I was hoping I could use drracket/check-syntax to analyse such files.
Screen Shot 2020-06-18 at 23.19.19.png 
Screen Shot 2020-06-18 at 23.19.19.png



Alex Harsanyi  11:24 PM
> We don't want a bunch of users creating their own ad-hoc solutions to this very common problem.
@badkins I have a feeling that, while several people agree that there is a problem, there is no agreement at all as to *what* the problem is and *how* to solve it.  I came up with my solution, which works for me, @Bogdan came up with his, which works for him, but other people don't find either solution satisfactory.  Perhaps further concrete proposals and pilot implementations will need to appear, and maybe one will emerge as a community favourite and will become the "official" one.

badkins:racket-flat:  11:26 PM
Well, I feel this is a very solved problem in other language communities. I suppose there are some subtle differences, but the problem seems clear enough to me. We have a history of operating system packages & numerous programming language package systems. I've used Bundler for years in Ruby, and it's done everything I've ever wanted.
11:29
I understand the strong desire for backward compatibility in the Racket community, and I think that's a strength, so I'm personally fine with changing the name of a package when it breaks backward compatibility. I realize others feel differently, but that's a separate problem from the issue of unintentional breakage due to the combination of bugs and package author's delay in fixing them. (edited) 
11:32
Having said that, once you solve this more important problem (which I think requires versioning), there's really no need to rename a package - just consider the version part of the name where a major version change indicates a backward incompatible change. (edited) 
11:32
has been called to supper, back later...

Alex Harsanyi  11:35 PM
@badkins you seem familiar wit Bundler and think it will be a good fit for Racket.  Do you volunteer to provide a pilot implementation, so the rest of the community can evaluate it to see if it fits their needs?

badkins:racket-flat:  12:11 AM
Since Bundler exists already, it's easy to evaluate - it seems to be well documented. There may be better managers, but I'm not familiar with them.
12:13
I think they all basically do the same thing - allow specifying a set of packages with a versioning scheme that's flexible enough to specify a variety of versions, and allow locking a set of packages at specific versions.
12:14
Seems like the first step is to simply allow something like raco pkg install foo@2.3.7  (I stole the @ from Julia)

notjack  12:18 AM
not sure how much has changed since it was published, but this post is a good summary of the state of the art https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
MediumMedium
So you want to write a package manager
You woke up this morning, rolled out of bed, and thought, “Y’know what? I don’t have enough misery and suffering in my life. I know what to…
Reading time
50 min read
Aug 1st, 2017
(114 kB)
https://miro.medium.com/max/1200/1*xFSWtpZd7YMLJXTClubYFA.jpeg

mflatt  12:19 AM
@notjack No one is suggesting that they want to write a package manager. People only want to give advice for someone else to do it.

notjack  12:19 AM
yup

badkins:racket-flat:  12:19 AM
C'mon guys...

notjack  12:19 AM
@badkins it is a full time job and then some to make one

badkins:racket-flat:  12:20 AM
I'd be content for folks to simply admit it's important to be able to install a specific version of a package.

notjack  12:20 AM
I think that's important, yes

badkins:racket-flat:  12:20 AM
Great, 'cause I got the sense that feeling is far from universal, so it's a good start.
:+1:
1


notjack  12:24 AM
I also think getting to that point will take a lot of work, way more than I'd be able to do as someone who writes Racket in my spare time for fun
12:24
and this is coming from someone who works on CI systems for a living

badkins:racket-flat:  12:37 AM
So @mflatt before I invest more time in this, is it safe to say the core team would be interested in enhancements to raco pkg that allow for 1) installing a specific version of a package, 2) specifying a set of versions for each dependency package, and 3) having a versioning scheme such as <major>.<minor>.<patch> where a bump in major number may break backward compatibility?

badkins:racket-flat:  12:45 AM
Rather than reinvent the wheel, I'd probably just go with RubyGems versions specifiers for dependencies:
Most of the version specifiers, like >= 1.0, are self-explanatory. The specifier ~> has a special meaning, best shown by example. ~> 2.0.3 is identical to >= 2.0.3 and < 2.1. ~> 2.1 is identical to >= 2.1 and < 3.0. ~> 2.2.beta will match prerelease versions like 2.2.beta.12. ~> 0 is identical to >= 0.0 and < 1.0.
https://guides.rubygems.org/patterns/#pessimistic-version-constraint (edited) 

samth  12:47 AM
@badkins I think that while people would like something like bundler, there are some tricky issues that make it not obvious what the best design for Racket is
12:47
Or, I should say, people would like the properties that bundler provides, as you say
12:48
I will try to write down some more of my thoughts here later this evening

badkins:racket-flat:  12:48 AM
Bundler-like functionality wouldn't be the first step. I'd rather build the bare minimum that makes sense to allow the fancier functionality to be built upon it i.e. the primitives.

mflatt  12:48 AM
@badkins I would say that everyone (core team included) would be interested in a worked-out implementation that does those things.

badkins:racket-flat:  12:50 AM
Awesome. I'm basically married to Racket for the long term now, so I'm going to need this eventually. For right now, I just need to solve the "I need these specific packages at these specific versions" problem regardless of how ugly/manual, but I'm happy to get involved in a longer term project that ends up with something like Bundler. I think I misread comments as pushback, so glad to hear I was mistaken.

samth  12:50 AM
I also have an idea that I think would accomplish the key thing you want without much change at all, but the kids have to go to bed first

badkins:racket-flat:  12:50 AM
I think @jeapostrophe’s "personal catalog" idea may get me there once I figure it out...
12:51
The non-git packages are a bit of a pain, but maybe racksnap will provide what I need there re: getting a previous version of a non-git package after the author has updated it an overwritten the package source with the latest.
12:53
I'm also wondering if an existing package manager couldn't be leveraged. I don't really see why something like Bundler couldn't be used for another language, but I may be missing something.

Alex Harsanyi  1:01 AM
If you are looking for a personal package catalog, you can just place packages you need in the same directory (use one directory for each package) and use the pkg/dirs-catalog command to create a catalog for these packages.  The blog post that I wrote uses essentially this approach, with the added step that the packages are managed as git submodules.  However, you can ignore the top half of the blog post, and the bottom half will show you how to create a personal catalog.

badkins:racket-flat:  1:02 AM
Thanks, I noticed that part of your blog post after I asked the question above. What's the best way to install packages on a server using that catalog?
1:04
I think the personal catalog approach is the 80/20 solution I need for now, and the web framework is both a higher priority, and something I'm better at, than a package manager. I'd probably be more likely to provide funding for the latter if push comes to shove.

Alex Harsanyi  1:20 AM
The remaining 20% is to use git and clone the directory with packages onto the server -- note that putting them somewhere else would not save you anything as the source code for the packages still needs to be downloaded.
1:22
There are also ways to create binary packages (which are tied to a particular Racket version and dependent packages) and put those in a catalog -- this would make installation and deployment faster, but managing them would be more complex -- I have not looked into this, so you'll need to read the Racket documentation for how to do this.

badkins:racket-flat:  1:24 AM
I'd rather not manually load packages into git.  If I have a well tested set of packages on my laptop, I think I can raco pkg archive - the docs state this will create a catalog from installed packages. Then I just need to provide access to that on the server. I suppose a worst case scenario might be scp'ing the directory to the server ?
1:25
Oh, it looks like you have to manually list all the packages with that approach :disappointed:

Alex Harsanyi  1:27 AM
you can create one "meta package" which depends all the packages you need, and archive that one, including all its dependencies

badkins:racket-flat:  1:28 AM
Gotcha. I should probably make my app a package, then I could just archive it w/ dependencies. I've been putting that off...

lexi.lambda  1:57 AM
@badkins About a year and a half ago, I wrote this comment about what concretely would need to be done to move towards a more Bundler-like world for Racket package management. I think it’s all still relevant, if you are interested. https://www.reddit.com/r/Racket/comments/9rn5ms/raco_package_versioning/e8jx6ws/
redditreddit
Raco Package Versioning
/u/Bourgond_Aries is right, there is no way to specify a dependency on a particular version (or range of versions) of a package. The package...
1:58
I don’t think the required effort to get something useful is that huge, since as I said, a lot of the technical foundations are already in place. But it’s big enough that nobody has done it.

badkins:racket-flat:  1:59 AM
Awesome - thanks. I really need to finish my web framework first, but package versioning may be the next thing I get involved in after that.
:+1:
1

2:00
I'm not sure I can attract non-lisp folks with the web framework (doesn't matter to me), but if I did, and they came from Ruby, Elixir, Python, etc., they're going to want versioning very soon :slightly_smiling_face:

badkins:racket-flat:  2:05 AM
@lexi.lambda long-term, I would certainly want what you describe in point 1, but I'd be fine with that coming later. #'s 2 & 3 would be a higher priority for me

lexi.lambda  2:06 AM
FWIW, I think point 1 is actually likely to be the easiest of those points to implement, since sandbox tethering already provides most of the required functionality. But I could be wrong.

badkins:racket-flat:  2:07 AM
I worked for years in a mode where I had multiple active projects with wildly different versions of libraries, so both Bundler and rbenv/rvm were very handy for having tons of different versions of ruby and various gems, but that's unpleasant :slightly_smiling_face:
2:07
Right now I just want to lock down packages so they're the same on my dev machine and server.

lexi.lambda  2:09 AM
Yeah, that makes sense. But just FYI, I think the Bundler model of generating a per-project bin/ directory with launcher executables that configure everything properly would work really naturally with the way the existing Racket infrastructure is set up.

badkins:racket-flat:  2:09 AM
Good to hear.
2:09
I'd be most competent on #2 at the moment.

lexi.lambda  2:10 AM
Yeah, I think most of the challenge of #2 is getting the UI right and handling backwards-compatibility gracefully.
2:11
The actual protocol changes should be very straightforward.

samth  2:30 AM
First, here's some overall thoughts. I think people with experience in other language package managers mostly miss the following things:
1. Being able to record the packages they depend on, and then check in something so they get the same packages when they rebuild in a different environment.
2. Having a per-project scope for packages, and being able to install different versions of a package for different projects.
3. Being able to specify specific versions of packages that you depend on, and have the package installation mechanism figure out appropriate versions of everything to install
4. Being able to have two different versions of a dependency appear in your dependency tree while everything keeps working.
2:31
There's also providing a smoother way of handling  backwards incompatible changes, but I think that's fundamentally separable

Alex Harsanyi  2:39 AM
From my personal point of view, I care about (1), (2) and (3).  I have solutions for (1) and (3) (some might call them workarounds, but I am happy with them), but (2) would be nice to have.
2:42
Also, (2) might be achievable, as suggested here: https://groups.google.com/d/msg/racket-dev/dHAFwzlFwNA/xfVGxIYaAgAJ, but I didn't have time to explore that option

samth  2:51 AM
I think the solutions for each of these ends up being pretty different, and it's important to think about the different goals here.
For 1, which is the problem that is most likely to cause things to go badly wrong, people have built a number of tools, such as racksnaps and the catalog mechanism in general, and @Alex Harsanyi has demonstrated how to put things together. But I think there are some other simple things that would help.
For example, a tool could rewrite your info.rkt file to change the dependency on "foo" to one on "git://github.com/bar/foo#hash". Then, assuming that repository stays in place, new installs would get exactly the same package content.
Of course, that's not perfect, but it could be further improved by adding a lock file that was separately consulted by raco pkg install.
Another simple thing would be for each dependency to allow specifying which catalog to look in -- then you could use different racksnaps for different packages.
None of these changes alter anything fundamental, but they would make the deployment safety use case easier.

samth  2:59 AM
For 2, the question is how much you want to share. If you don't care about any sharing, you can just have multiple racket installs and never use user scope (this is basically what I do). The tethering approach @mflatt described lets you share more, but all the installations have to share the same version of everything shared, and everything those packages depends on. One question in this situation is the role of DrRacket. Basically, if different projects need different versions of one of DrRacket's dependencies, then you'd need multiple copies of DrRacket.
3:03
For 3, some bigger changes to the protocol are required -- the server needs to remember how to get past version, and has to know when a new version has been released. pkgs.racket-lang.org doesn't store package content, and I don't think we want to change that, so that's one constraint.
However, I think something in this area is doable, but it would be a lot of work in a number of places.

samth  3:12 AM
For 4, I think it's much harder. There are two big challenges that I see. One is that the collections system assumes that collection paths are unique, and installing two versions of the same package would almost certainly break that.
The other, more subtle issue is you'd probably end up with bugs related to the two copies trying to interact and failing, typically because the different struct definitions would produce distinct types.
This is a fundamental problem with this idea in any language, but most other languages don't have it as bad as Racket. In Haskell or Rust, either the incompatible type is exposed in the interface or it isn't. If it isn't, there's no problem, and if it is, there's a type error.
In Python or JS or Ruby, typically values from external libraries are treated structurally, ie using duck typing. So the instances play well together in most cases.
Racket is somewhat unique in being untyped but relying heavily on nominal tags.
Of course, even in other languages two versions of a  package could do something weird and conflict using the filesystem or other hidden state in a way that caused subtle bugs, but it's much rarer.
Notably, this is a problem that came up regularly with PLaneT, the previous package system. There ended up being some metadata that said whether this meant the two installs should be prohibited, but there's only so much that this can really be solved.

samth  3:18 AM
Finally, on the issue of backwards incomparable changes, I think this could be addressed by having packages grow an additional field (say edition) which would basically be part of the name, except that you'd write it separately in the info.rkt file and all the different editions of a package would show up together on the package web site. This would be a pretty small change to the system but would make this use case much easier to handle than currently, where you basically add a digit to your package name. Note that widespread use of this would exacerbate problem 4 above (one reason that I prefer the "maintain compatibility" approach).
3:21
Well, that was a lot of text. Hopefully that helps, @badkins. And I'm interested in other people's thoughts who are interested in the package system @lexi.lambda @Bogdan @notjack
And I should say that I'm potentially interested in implementing some of the simpler ideas for 1 & 2, but it is not at the top of my stack right now.

lexi.lambda  3:23 AM
I think the comment I linked above (which you responded to, so I know you read it at one point) is essentially consistent with what you’ve just written, albeit it doesn’t include a direct analog to point 1.

jaz  3:24 AM
IIRC, bundler (and some other package systems) don't attempt to solve (4); they require that the dependencies of a given application agree on a single version of any one package. (edited) 
3:25
Though not solving that problem adds a different one: figuring out which, if any, version can be used given all the dependencies.

lexi.lambda  3:26 AM
Yes, I agree; my comment proposes a Cabal-/Bundler-esque model, not an npm-esque one. The latter seems theoretically useful but very hard to get to from where we are right now, and I don’t think it’s essential to the usefulness of the system.
3:31
I do think your explicit discussion of DrRacket is a very good point that I didn’t mention explicitly. In some ways it is rather at odds with the DrRacket philosophy: it would mean having a DrRacket installation per project, but DrRacket is supposed to be an operating system! Historically Racket has gone to great lengths to allow DrRacket to run everything in-process, without the need for some extra-linguistic mechanism, but this would be an explicit compromise on that point.
3:32
That said, I think the current package system is already an explicit compromise on that idea, relative to PLaneT. So that isn’t really new, it’s just a deeper ramification than we’ve seen so far.






 
 