@dmitryhertz a limited form of continuations are used to implement exceptions, and they’re used in the web server a bunch

Is there a machine readable format of all the packages which include the checksum on https://pkgs.racket-lang.org ?

@setori88 https://pkgs.racket-lang.org/pkgs-all

Ah yes, just found that, thanks

I see many packages simply mention source with no version, am I to take that the racket community have a convention of using master as the definitive version? To describe my question better, I see one occurance of name . "base" implying there is one base package, yet there are multiple references to different base versions in other package dependencies e.g. ("base" #:version "6.8.0.2") and ("base" #:version "6.2.900.6"). How does racket know to checkout the correct version? Are the packages stored as git repos in the local racket packages checkout directory? Then racket will quickly checkout the tag, load the code into memory then rinse and repeat for every version? Normally, every versioned reference of base in pkg dependencies should be accompanied by a separate definition of base with an explicit matching version.

A version is intended to reflect available features of a package, and should not be confused with different releases of a package as indicated by the checksum. - https://docs.racket-lang.org/pkg/Package_Concepts.html?q=%23version#%28tech._version%29

@setori88 yes, it’s common to use master as the definitive version. if you use a package backed by a git repo, it fetches the data from the git repo but doesn’t do a clone. if you want to do a clone so you can use git operations, you can use the --clone option

I’m quite happy to see master as definitive version, it reduces dependency calculation considerably. This way just the package name is needed when in semantic versioning and other atrocities the actual name of a package is name+version hence you have n packages all doing approximately the same thing. Now releasing on master means the racket community doesn’t remove or change previously exported function names I hope. I also take it one cannot delete a package from http://pkgs.racket-lang.org\|pkgs.racket-lang.org! Are these conventions documented anywhere?

@setori88 right, the convention is to try to maintain backwards compatibility always

and to create a new package if you need to break something

perfect, very happy to hear this.

:slightly_smiling_face:

it does have tradeoffs - maintaining constant backwards compatibility is both extraordinarily difficult and quite limiting. There’s interest in exploring alternatives for racket.