Skip to content
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

Closed
wants to merge 22 commits into from
Closed

Conversation

alejandrosame
Copy link
Contributor

@alejandrosame alejandrosame commented Oct 8, 2023

This PR moves the Hyperspace monorepo into this monorepo.

To complete the migration, I made the following:

  • git subtree added the original repo.
  • checked that it would work with the same nixpkgs pinned in ngipkgs inputs.
  • extracted packages from original monorepo into by-name packages with the dream2nix V1 API (previous API is deprecated).
  • added installation checks for each individual package .

Closed because it was split into multiple PRs (rationale)[https://github.com//pull/67#issuecomment-1870770659]:

Tracking issue: #12.

@lorenzleutgeb
Copy link
Member

I have no experience with dream2nix, but I am asking myself whether package.nix and d2n-files/default.nix (per package) can be merged, so that we only have package.nix and even get rid of the d2n-files folder. That would be a lot leaner. I'd like to understand. Probably I should RTFM, but maybe you know and can tell me why the d2n-files/default.nix is required?

@alejandrosame
Copy link
Contributor Author

@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.

@alejandrosame
Copy link
Contributor Author

@lorenzleutgeb with the help of @DavHau, this PR now makes it possible to add packages by-name and using dream2nix to evaluate them as modules.

In order to distinguish packages as modules from callPackage ones, the former need to be called module.nix inside it's named folder.

Copy link
Member

@lorenzleutgeb lorenzleutgeb left a 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]>
@augustebaum
Copy link
Contributor

@lorenzleutgeb We applied all of these suggestions, please have a look when you can.

Copy link
Member

@lorenzleutgeb lorenzleutgeb left a 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:

  1. Name and version.
  2. Imports.
  3. Sources.
  4. Unpacking and Patching.
  5. Dependencies (general definition, overrides, vendor hashes etc.)
  6. Configuration of phases, in the order that they are executed.
  7. Passthrus
  8. 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]>
@augustebaum
Copy link
Contributor

We ended up moving the name and version but not much else; as you said, with this dream2nix it's a bit harder to enforce the order of the callPackage convention.

@lorenzleutgeb lorenzleutgeb changed the title Migrate Hyperspace packages to monorepo Migrate hyperspace Oct 24, 2023
Copy link
Member

@lorenzleutgeb lorenzleutgeb left a 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.

@@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- run: nix flake check --debug --print-build-logs
- run: nix flake check --verbose --print-build-logs

Copy link
Contributor

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.

@@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- run: nix flake check --debug --print-build-logs
- run: nix flake check --verbose --print-build-logs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@lorenzleutgeb lorenzleutgeb Oct 25, 2023

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.

@lorenzleutgeb
Copy link
Member

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 --debug --print-build-logs. The logs are very large (506MiB). The job is killed while it's compiling some Rust code. Probably because the logs are getting too big?! I don't think it's a timeout...

$ du -b log.txt
531484614       log.txt
$ head -n 6 log.txt
2023-10-25T13:44:51.0331804Z ##[group]Run nix flake check --debug --print-build-logs
2023-10-25T13:44:51.0332586Z nix flake check --debug --print-build-logs
2023-10-25T13:44:51.0379294Z shell: /usr/bin/bash -e {0}
2023-10-25T13:44:51.0379736Z env:
2023-10-25T13:44:51.0380281Z   MAGIC_NIX_CACHE_DAEMONDIR: /home/runner/work/_temp/magic-nix-cache-cMmTgQ
2023-10-25T13:44:51.0380970Z ##[endgroup]
$ tail -n 2 log.txt
2023-10-25T14:23:02.8720999Z rosenpass>    Compiling serde_derive v1.0.185
2023-10-25T14:23:20.1459141Z ##[error]The operation was canceled.

@alejandrosame
Copy link
Contributor Author

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 dream2.nix instead of using module.nix inside each by-name folder.

The list of PRs is:

@alejandrosame
Copy link
Contributor Author

I'll go ahead and start merging the separate PRs, since this one was only stalled because CI never got green.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants