|3 years ago|
|.circleci||3 years ago|
|.github||3 years ago|
|cli||3 years ago|
|data||4 years ago|
|docs||3 years ago|
|misc||3 years ago|
|services||3 years ago|
|tools/vcpm-sync||3 years ago|
|.all-contributorsrc||4 years ago|
|.dockerignore||3 years ago|
|.editorconfig||4 years ago|
|.eslintrc||3 years ago|
|.gitignore||3 years ago|
|.mailmap||3 years ago|
|.markdownlint.json||3 years ago|
|.prettierrc||3 years ago|
|CODE_OF_CONDUCT.md||3 years ago|
|LICENSE||4 years ago|
|README.md||3 years ago|
|docker-compose.yml||3 years ago|
|package-lock.json||4 years ago|
|package.json||3 years ago|
Entropic: a federated package registry for anything
A new package registry with a new CLI, designed to be easy to stand up inside your network. Entropic features an entirely new file-centric API and a content-addressable storage system that attempts to minimize the amount of data you must retrieve over a network. This file-centric approach also applies to the publication API. See the API section of the manifesto for more details about the API offered.
Entropic assumes many registries co-existing and interoperating as a part of your normal workflow. All Entropic packages are namespaced, and a full Entropic package spec also includes the hostname of its registry.
The legacy node package manager is treated as a read-only archive. You may install legacy packages through your Entropic home instance.
See docs/README.md for the manifesto.
Are you interested in contributing? Do you have some feedback to share? Come talk with us in our Discourse.
Entropic is self-hosting. That means login, publication, and installation (mostly) are working. There are bugs, many unimplemented features, and the whole thing will probably fall over in a stiff breeze. We feel this is exceeding expectations for a project that's just over a month old.
Our development instance is running at
https://registry.entropic.dev/. You'll probably all knock it over trying it out, I just know it.
Package specifications are fully qualified with the namespace, hostname, and package name. They look like this:
email@example.com/pkg-name. For example, the ds cli is specified by
If you publish a package to your local registry that depends on packages from other registries, your local instance will proactively mirror all the packages yours depends on. The goal is to keep each instance entirely self-sufficient, so installs don't have to depend on a resource that might vanish. This is also true of packages installed from the legacy node package manager: they're given the namespace
legacy and mirrored.
Abandoned packages are moved to the
Every Entropic user has a namespace that matches their user name. They may additionally belong to other namespaces. Packages can be updated by any user in the package's namespace. Packages can also have a list of maintainers.
For example, user
chris owns the package
firstname.lastname@example.org/ds. Chris can invite
ceejbot to maintain
ds. If ceejbot accepts, they'll be able to publish new versions of
ds. Meanwhile, the package
email@example.com/lodash can be maintained by anybody who's a member of the
lodash-people namespace. This might include the user
jdalton and anybody else jdalton invites. (We hear that jdd gets a dollar every time somebody uses lodash as an example.)
All packages published to Entropic are public. Our expectation is that you'll use something like the GitHub Package Registry if you need to control access to packages you publish. Or you might choose to run an Entropic instance and control access to it another way.
See INSTALLING to install.
Log in to a registry:
ds login. You will be prompted to authenticate using Github.
ds cli is configured with an
.entropicrc file in your home directory. This is a TOML file. Use it to specify your preferred registry, as well as any other registries you use normally.
registry = "http://example.com" [registries."https://entropic.dev"] token = "a-valid-entropic-token" [registries."http://example.com"] token = "another-valid-entropic-token"
The cli doesn't have a very sensible shell for running commands yet, and it doesn't yet have working help. (Help for help welcomed!) You can see what commands are implemented by browsing the command source folder. See the cli readme for more notes.
At present, if you want to install packages using
ds, you can run
ds build in a directory with a
Package.toml. This will produce a
ds/node_modules directory, which you can move into place by hand. This is a temporary situation!
Packages are described by TOML files giving metadata and listing dependencies.
Here's an example
name = "firstname.lastname@example.org/ds" version = "0.0.0-beta" [dependencies] "@iarna/toml" = "^2.2.3" "email@example.com/figgy-pudding" = "^3.5.1" [...]
Publish a new package-version with
Entropic is, at the moment of this writing, the work of two people: Chris Dickinson and C J Silverio. They are not sponsored by anybody nor do they represent anyone but themselves. Chris and Ceej are seeking additional contributors but wish to onboard newcomers slowly. The project is new enough that clear direction does not always exist in the code, so contributors will need to work closely with us.
This project is released under the Apache 2.0 license.