-
-
Notifications
You must be signed in to change notification settings - Fork 232
feat: Implement support for Github-based index, bypassing the registry #3023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
✅ PR OK, no changes in deprecations or warnings Total deprecations: 0 Total warnings: 0 Build statistics: statistics (-before, +after)
-executable size=5055872 bin/dub
-rough build time=61s
+executable size=5511744 bin/dub
+rough build time=65s Full build output
|
This is what the output looks like for Configy:
{"version":0,"name":"configy","description":"An automatic YAML to struct configuration parser for dlang","source":{"kind":"github","owner":"dlang-community","project":"configy"},"versions":[{"version":"2.1.0","subs":[{"configurations":[{"dependencies":{"dyaml":">=0.8.4"},"name":""},{"name":"library"},{"name":"debug"},{"name":"unittest"}],"path":"dub.json","cache":{"etag":"W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"","last_modified":"Thu, 10 Apr 2025 00:06:18 GMT"},"name":""}],"commit":"f161db12e7f6462959b9f42edd4301a252f13dfe"},{"version":"2.0.0","subs":[{"configurations":[{"dependencies":{"dyaml":">=0.8.4"},"name":""},{"name":"library"},{"name":"debug"},{"name":"unittest"}],"path":"dub.json","cache":{"etag":"W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"","last_modified":"Thu, 10 Apr 2025 00:06:18 GMT"},"name":""}],"commit":"c66665417289da4e8f8ede16a96e8158efd499b5"},{"version":"1.0.0","subs":[{"configurations":[{"dependencies":{"dyaml":">=0.8.4"},"name":""},{"name":"library"},{"name":"debug"},{"name":"unittest"}],"path":"dub.json","cache":{"etag":"W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"","last_modified":"Thu, 10 Apr 2025 00:06:18 GMT"},"name":""}],"commit":"110cc0600324f091773d979284d2948a9ddbb975"}],"cache":{"etag":"W/\"3d57862ee06488642331352dfd274351c5417a254c7c7f0523fab18fee8d9d36\"","last_modified":"Tue, 15 Apr 2025 15:51:57 GMT"}} Or, pretty-printed: {
"version": 0,
"name": "configy",
"description": "An automatic YAML to struct configuration parser for dlang",
"source": {
"kind": "github",
"owner": "dlang-community",
"project": "configy"
},
"versions": [
{
"version": "2.1.0",
"subs": [
{
"configurations": [
{
"dependencies": {
"dyaml": ">=0.8.4"
},
"name": ""
},
{
"name": "library"
},
{
"name": "debug"
},
{
"name": "unittest"
}
],
"path": "dub.json",
"cache": {
"etag": "W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"",
"last_modified": "Thu, 10 Apr 2025 00:06:18 GMT"
},
"name": ""
}
],
"commit": "f161db12e7f6462959b9f42edd4301a252f13dfe"
},
{
"version": "2.0.0",
"subs": [
{
"configurations": [
{
"dependencies": {
"dyaml": ">=0.8.4"
},
"name": ""
},
{
"name": "library"
},
{
"name": "debug"
},
{
"name": "unittest"
}
],
"path": "dub.json",
"cache": {
"etag": "W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"",
"last_modified": "Thu, 10 Apr 2025 00:06:18 GMT"
},
"name": ""
}
],
"commit": "c66665417289da4e8f8ede16a96e8158efd499b5"
},
{
"version": "1.0.0",
"subs": [
{
"configurations": [
{
"dependencies": {
"dyaml": ">=0.8.4"
},
"name": ""
},
{
"name": "library"
},
{
"name": "debug"
},
{
"name": "unittest"
}
],
"path": "dub.json",
"cache": {
"etag": "W/\"f414b8246bf2fe14ae009a0952945d8d25c824d8\"",
"last_modified": "Thu, 10 Apr 2025 00:06:18 GMT"
},
"name": ""
}
],
"commit": "110cc0600324f091773d979284d2948a9ddbb975"
}
],
"cache": {
"etag": "W/\"3d57862ee06488642331352dfd274351c5417a254c7c7f0523fab18fee8d9d36\"",
"last_modified": "Tue, 15 Apr 2025 15:51:57 GMT"
}
} One way to reduce the bloat would be to have another step to only publish data that is relevant (currently the index stores all the etags / last modified to avoid needlessly querying Github). I would also like to look into package popularity (number of stars / forks, etc...). |
1aa5d9f
to
8e86aa7
Compare
I can see 103 dead packages:
|
8e86aa7
to
e6ed130
Compare
e6ed130
to
b48f09e
Compare
This way we can parse things that are not YAML 1.1 compliant.
This implement a package 'index' similar to that found for Homebrew, Nix, Cargo, etc... It allows us to remove a SPOF in our critical infrastructure, as a Github outage would always cause a registry being unusable anyway. There are multiple steps to having a useful index: - For transition purpose, we add a hidden command to Dub that export an `index.yaml`; - In the future, users should register their packages by adding an entry to `index.yaml`, the index definition file of the registry. This is used as the source of all packages; - `dub` now has a hidden `index-build` command to allow it to build the index based on an index definition file (`index.yaml`). Using this, it queries the various APIs to generate JSON index files that are stored under a pre-defined hierarchy. - Finally, a `PackageSupplier` is added to make use of this new feature; In the future, the registration process needs to be moved from the registry to Github to make this migration complete. This *can* be done by exposing a user-friendly interface on `code.dlang.org`, if making an MR to the index is deemed too complicated.
b48f09e
to
be764c1
Compare
While I'm not opposed to this approach in general, we should set the bar for this quite high:
The thing I'm not quite sure about is what we gain by using GitHub to store the list of packages. If that's the only centrally served asset, that should also be trivial to do from a dlang server that is independent of the registry web frontend. It should be mentioned that we already had a working fallback mechanism with <codemirror.dlang.org> et.al., but at some point along the way that obviously broke. We should definitely get that fixed again and maybe look into improving it (for example, skipping a server that timed out or yielded a 5xx error). |
I missed Gitea. The rest are supported. Note that there is currently no public package using Gitea. But it shouldn't be hard to add.
I think there's multiple questions this raises. Do we want to have private repositories on the public index ? I'd say no. So it's more about supporting different repositories, which this should be able to do, but I haven't extensively tested it yet.
Still need to do that, but definitely on the list.
Agreed - also need to make sure we make it cache / CI friendly.
We could add various metrics to Dub, but also we could rely on Github's metrics / Stars / Forks.
I don't think this affects our ability to back up packages in any way, positively or negatively. However it makes ownership transfer much easier (because there's no longer a notion of ownership), and thus reviving a dead package no longer needs to involve an administrator.
A lot less to maintain, and a well-known access model.
Agreed we need to improve the client side of thing. But if we can remove most concerns on the server side, that'll be a win in terms of work to be done. |
This is still a WIP, albeit quite complete now. Things that still need to be done:
Description is not handled properly (needs to be extracted from the recipe file);Need to switch configy to a real JSON backend as the YAML one doesn't handle strings well.FYI @s-ludwig