Racket’s existing package system doesn’t pose any felt problems for me, but I still find this project very interesting.
On some future day when Xiden is out of beta, what are authors of “normal” Racket packages doing to make their packages available to Xiden users? For example, are we zipping, hashing and signing every “release” and uploading it somewhere (our own web server or a 3rd party catalog)? Or is the typical Xiden user manually creating their own catalogs and packages from others’ code after a thorough vetting? (Maybe if I were more familiar with Guix I would already know the answer to this) On Friday, March 19, 2021 at 3:56:18 PM UTC-5 Sage Gerard wrote: > Hi folks, > > About a year, 1384 commits, 489 tests, ~10k LOC, and 2" on my waistline > later, Xiden is in beta. An update is pending on the default catalog. > > https://github.com/zyrolasting/xiden > > Xiden is a dependency manager I wrote to support use cases that I could > not get working with `raco pkg`. > > Dependency management is hard, so Xiden was something I originally didn't > want to make. However, it ended up becoming one of my most aspirational > projects, and I'm proud of how it ended up. If you could take the time to > read a longer email, I'd like to share a bit about how it might be helpful > to you. > > *** > Like Guix, Xiden supports deterministic and atomic installations. Unlike > Guix, Xiden is cross-platform. > > The Racket programs I write no longer have to assume that code comes in > collections (outside of the built-in ones). > > You can force dependencies of different versions to resolve to the same > data to avoid issues with non-eq? bindings [multiver]. > > Dependencies are accessed by symbolic links with names defined by the > dependent. So if two packages are called "uri", you can still install them > both under names that are meaningful to you. Dependencies are fulfilled the > same way, regardless if the dependent is a human or more software. > > Explicit, affirmative consent is fundamental to Xiden's workings. The > default configuration is zero-trust (a.k.a. "Deny All"). Trust in > cryptographic hash functions and public keys (or any bytes lacking either) > *must* be declared to authenticate bytes from *any* source (even hard > coded!). Not doing so will cause Xiden to reject data, but print an error > that helpfully instructs you how to consent to the scenario. For those > wanting convenience, there are "blanket" configuration options to consent > to every instance of those scenarios. This makes Xiden a way to educate > users on the exact shape and nature of the risks they accept with something > from the Internet. In this sense, Xiden does not invent anything new with > security. It only aims to get ahead of the "Allow Some" arms-race in other > dependency managers like NPM. > > Customization comes from a plugin module. You can use a plugin to > integrate GPG, use a different archive format, or otherwise fill in gaps in > Xiden's functionality. Xiden keeps authentication and integrity checking > decoupled in this way so that users can transition on their own in the > event a smart person finds a collision in a CHF, or cracks a cipher. > Similarly, Xiden's data sources are any data type declared with a path to > an input port, including queries to a catalog. A neat effect of this is > that you can configure your own syntax for data sources in your command > lines. > > Even though I call Xiden a dependency manager, it is generalized enough to > be useful as a component for a CI system, as a self-hosted OS development > environment, or even as a back-end for a more specialized dependency > manager. > > If this is something that interests you, please consider trying the > examples with the guide [ex][guide]. Like all software, Xiden is not > perfect, so I depend on your feedback to make Xiden better for you, and to > decide what interfaces should be declared stable. > > [ex]: https://github.com/zyrolasting/xiden/tree/master/examples > [guide]: https://docs.racket-lang.org/xiden-guide@xiden/index.html > [ethos]: > https://groups.google.com/g/racket-users/c/4iI-SanIbzk/m/sGHYijLPAAAJ > [multiver]: > https://github.com/zyrolasting/xiden/tree/master/examples/01-differing-versions > > -- > ~slg > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/932af4c4-3713-4305-970b-e608e434a71en%40googlegroups.com.
