-
Notifications
You must be signed in to change notification settings - Fork 19
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
Migrate hyperspace
#67
Conversation
Co-authored-by: Bill Ewanick <[email protected]> Co-authored-by: a-kenji <[email protected]> Co-authored-by: Matthias Meschede <[email protected]>
I have no experience with dream2nix, but I am asking myself whether |
@lorenzleutgeb I simply started from the examples in the current d2n repo. The reason it's there is because there are only examples of "drea2nix monorepos". So I already generalized it to contain only a package. I can still try to merge them further, it might still be possible. I just made this PR after a bunch of refactors that left this code in a functional and OK state. I'll also ask for single package examples upstream. Worst case, I could extract away the current boilerplate in a function and add it to the scope. |
hyperspace: refactor to use dream2nix with by-name architecture
@lorenzleutgeb with the help of @DavHau, this PR now makes it possible to add packages In order to distinguish packages as modules from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, looks much better!
The package names are missing version numbers. Is that intentional? Why?
nix flake show --json | jq -r '.packages."x86_64-linux"[].name' | sort
atomic-cli-0.34.5 atomic-server-0.34.5 autobase corestore flarum-1.8.0 gnunet-messenger-cli-0.1.1 hyperbeam hyperblobs hypercore hyperswarm lcrq lcsync libgnunetchat librecast nixos-system-server-23.11.20230919.8b5ab83 nixos-system-server-23.11.20230919.8b5ab83 nixos-system-test-flarum-23.11.20230919.8b5ab83 pretalx-2023.1.3 pretalx-2023.1.3 pretalx-frontend-2023.1.0 python3.10-euclid3-0.01 python3.10-kikit-1.3.0 python3.10-pcbnewTransition-0.3.4 python3.10-pretalx-downstream-1.1.5 python3.10-pretalx-media-ccc-de-1.1.1 python3.10-pretalx-pages-1.3.3 python3.10-pretalx-public-voting-1.3.0 python3.10-pretalx-venueless-1.3.0 python3.10-pybars3-0.9.7 python3.10-pymeta3-0.5.1 rosenpass-0.2.0 rosenpass-tools-0.2.0
I do understand that there are other packages that are also missing versions...
Also I saw that you have version = "v" + # ...
, i.e., version prefixed with 'v' in some of the modules. Again, this is unusual. Any particular reason?
And lastly, there's no meta information at all, it seems. Could you please add that?
Co-authored-by: Alejandro Sanchez Medina <[email protected]>
@lorenzleutgeb We applied all of these suggestions, please have a look when you can. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! But I have one more request: Please reorder the contents of the modules. A logical order (for me), is the following:
- Name and version.
- Imports.
- Sources.
- Unpacking and Patching.
- Dependencies (general definition, overrides, vendor hashes etc.)
- Configuration of phases, in the order that they are executed.
- Passthrus
- Meta-Attributes.
I do understand that (4.) refers to phases, but these are the phases that are logically very tightly connected to definition of the source.
For this PR, I guess this boils down to moving name
and version
to the start of the module.
Again, this is my opinion, so if you don't agree you can reorder things in different ways. But a widespread convention is to put package name and version first, and meta-attributes last. I strongly recommend you do at least that.
Other than that, good to merge IMO!
This is because they time out after 1 hour even though they pass locally. Co-authored-by: Alejandro Sanchez Medina <[email protected]>
We ended up moving the |
hyperspace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason to go for --debug
? Seems excessive to me, --verbose
should do.
.github/workflows/pull_request.yaml
Outdated
@@ -15,4 +15,4 @@ jobs: | |||
- uses: DeterminateSystems/magic-nix-cache-action@main | |||
with: | |||
upstream-cache: https://ngi.cachix.org/ | |||
- run: nix flake check | |||
- run: nix flake check --debug --print-build-logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- run: nix flake check --debug --print-build-logs | |
- run: nix flake check --verbose --print-build-logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was added for testing as we cannot replicate the failure locally; we will probably revert this change when the issue is resolved.
.github/workflows/push.yaml
Outdated
@@ -16,4 +16,4 @@ jobs: | |||
with: | |||
name: ngi | |||
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}' | |||
- run: nix flake check | |||
- run: nix flake check --debug --print-build-logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- run: nix flake check --debug --print-build-logs | |
- run: nix flake check --verbose --print-build-logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #67 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. In such cases consider creating a new branch on top of the branch you are trying to merge, make the failure-diagnosis related changes in a new commit, and push to the new branch. That way there'll be no noise in the PR, and once you've resolved the issue, you can commit it to the PR branch. No big deal about the change in this instance, I am just trying to share a tip here.
Also note that this won't work for Actions that run on pull request only, like the one in .github/workflows/pull_request.yaml
. That's why I am commenting here.
Leaving this unresolved, so that we don't forget to remove the debugging flags.
Regarding CI failures, I am slightly confused. Checks are green on e7be932, the last commit that actually has changes that are related to the PR. Checks fail on eb84483, the commit that "just" adds
|
eb84483
to
98f30c1
Compare
After many tries to figure out what was wrong with CI failures, I decided to split the individual packages into separate PRs. It was quite puzzling that #82 consistently worked with any combination of 5 packages but ended up failing when adding the 6th. I took the opportunity and applied the naming convention proposed in #74. This means, using The list of PRs is: |
I'll go ahead and start merging the separate PRs, since this one was only stalled because CI never got green. |
This PR moves the
Hyperspace
monorepo into this monorepo.To complete the migration, I made the following:
git subtree
added the original repo.ngipkgs
inputs.by-name
packages with thedream2nix
V1 API (previous API is deprecated).Closed because it was split into multiple PRs (rationale)[https://github.com//pull/67#issuecomment-1870770659]:
Tracking issue: #12.