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

Init: chromium darwin #244152

Closed
wants to merge 3 commits into from
Closed

Conversation

michaelCTS
Copy link

@michaelCTS michaelCTS commented Jul 18, 2023

Description of changes

Provides a simple chromium package for darwin as well as a makeDarwinApp.

There are still some possible improvements, but I would like to keep this PR small and add those improvements in later PRs instead of having one enormous PR.

  • an update script
  • a common mkDerivation.meta (though that may be messy)
  • makeDarwinApp should be able to retrieve the version from the source (Info.plist should contain a field with the app version)

Notes

The diff looks like chromium/default.nix was edited, but I moved it all into chromium/linux and created a new one. The diff is unfortunately not better, but I hope that won't be a problem

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 23.11 Release Notes (or backporting 23.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

closes #247855

@michaelCTS michaelCTS self-assigned this Jul 18, 2023
@michaelCTS michaelCTS added the 6.topic: darwin Running or building packages on Darwin label Jul 18, 2023
@michaelCTS michaelCTS force-pushed the chromium-darwin branch 2 times, most recently from a960814 to 80633f7 Compare July 18, 2023 11:50
@michaelCTS michaelCTS requested review from soupglasses, primeos and a user July 18, 2023 11:59
@michaelCTS michaelCTS force-pushed the chromium-darwin branch 3 times, most recently from f479f21 to 1ea3326 Compare July 18, 2023 14:57
@ofborg ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Jul 18, 2023
Copy link
Contributor

@toonn toonn left a comment

Choose a reason for hiding this comment

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

Would be nice if we could get a Linux maintainer's opinion on the reorganizing of the package.

@ghost
Copy link

ghost commented Jul 18, 2023

Would be nice if we could get a Linux maintainer's opinion on the reorganizing of the package.

Yeah that reorg is going to create a massive merge conflict with pending PRs like #229265.

ghost
ghost previously requested changes Jul 19, 2023
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

Since chromium is built from source and this isn't, they zero Nix code; there's really no benefit to having them be the same package. @toon had the right idea; rename this to chromium-bin and put an if stdenv.hostPlatform.isDarwin then chromium-bin else ... in pkgs/top-level/all-packages.nix.

@michaelCTS
Copy link
Author

@amjoseph-nixpkgs there doesn't seem to be an existing chromium-bin. There wouldn't be a need for if stdenv.hostPlatform.isDarwin then chromium-bin else ... in all-packages.nix, correct?

@ghost
Copy link

ghost commented Jul 19, 2023

@amjoseph-nixpkgs there doesn't seem to be an existing chromium-bin.

Right; I was suggesting that you create one. But, as you point out:

There wouldn't be a need for if stdenv.hostPlatform.isDarwin then chromium-bin else ... in all-packages.nix, correct?

I guess if you really want to avoid creating another top-level entry you could just have callPackage ../applications/networking/browsers/chromium/darwin.nix {}.

The -bin convention is pretty well-established, though. We have 163 packages in all-packages.nix with the -bin suffix (including firefox).

@michaelCTS michaelCTS force-pushed the chromium-darwin branch 3 times, most recently from 0ef984b to 53ce772 Compare July 19, 2023 17:47
@ghost ghost dismissed their stale review July 19, 2023 19:51

Changes implemented. Thanks!

@ghost
Copy link

ghost commented Jul 19, 2023

Hey, looking much better, thanks a bunch for reorganizing this. I'll leave the rest of the review up to people who have Darwin hardware to test on. Nice work!

@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin and removed 10.rebuild-darwin: 1-10 labels Jul 20, 2023
It's not clean, but it works.
What's missing is an update script and how to get the actual version without downloading the entire archive first.

extractDarwinApp is a helper for making derivations from
.app and .dmg bundles.
Copy link
Contributor

@toonn toonn left a comment

Choose a reason for hiding this comment

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

Much simpler this way, I think making a new package was for the best.


mkdir -p $out/bin
if [[ "${toString isDmg}" = "1" ]] ; then
# .dmg uses sourceRoot, which means PWD is already in the sourceRoot
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't we avoid setting the sourceRoot to inside the .app bundle so that we can do away with these branches and just copy the bundle in both cases?

Copy link
Author

Choose a reason for hiding this comment

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

There are multiple usecases.

  1. the source is unpacked to contain a folder with a single subfolder ${appName}.app/

That means we can copy the subfolder with no processing

  1. the source is unpacked to contain a folder with multiple subfolders of which one is the .app folder

This makes the default unpackPhase unhappy as it expects only a single folder https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L1136
It is that error which added the necessity for sourcesRoot.

  1. the source is a folder

I'm now noticing that this isn't supported by the function in its current form.

But this can be the most difficult or the easiest, depending on how it's handled. The reason being at some point the there's a cd into the folder by mkDerivation --> a ${appName}.app folder will reveal Contents/ when a ls is run in the installPhase.

This means, either similar processing to now which still requires branching, or detecting whether it's a valid bundle and then doing processing like is done now.


If you have a suggestion to handle this without branching, that'd be great.

Copy link
Author

Choose a reason for hiding this comment

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

2f85c6e treats all the usecases above but with the existing branches. I couldn't conceive a solution without branches.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just setting sourceRoot = "." should work. It only makes passing an app as the source slightly harder but I don't think that'd be a common case?

Copy link
Author

Choose a reason for hiding this comment

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

It does seem like a valid usecase. Is it a problem that it's handled?

Copy link
Contributor

Choose a reason for hiding this comment

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

It makes everything more complex for very little gain though. When would you want to use a straight app as source and be unable to use the directory containing it instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

@michaelCTS, do you disagree strongly with the simplification?

Copy link
Author

@michaelCTS michaelCTS Sep 15, 2023

Choose a reason for hiding this comment

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

Yes, I do. It's not clear to me why we would remove support for a usecase just because of a single if/else, and wait until/if someone does stumble upon the usecase to then have another discussion about a conditional block.

Edit: I currently don't have the bandwidth to make modifications anyway, so it's OK with me if you edit it or even fork it and make another PR. You should have edit access now

Michael Vogel added 2 commits July 25, 2023 17:32
The arguments and documentation implied that only `.app` and `.dmg`
we supported, but that wasn't true.
The case for `src = ./some/folder` and non-dmg archives with multiple
folders was not supported.

Now, the user can specify srcHasManySubfolders which sets the
`sourceRoot` for `mkDerivation` to a default value.
The user also can directly set `sourceRoot` themselves.
This allows nix to handle the supported platforms
instead of throwing a string for unsupported platforms.
@jakuzure
Copy link
Contributor

Hey, looking much better, thanks a bunch for reorganizing this. I'll leave the rest of the review up to people who have Darwin hardware to test on. Nice work!

I just tried it out via home-manager (set the package option to chromium-bin) and it seems to be working fine. I couldn't get the extensions option to work though, but that might be related to the bin maybe? Installing them directly in the browser worked fine

@michaelCTS
Copy link
Author

@jakuzure thanks for testing. Not sure what's up with the extensions in home-manager and how it's implemented. A related issue would have to be created there if this is merged.

@wegank wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Mar 19, 2024
@WeetHet
Copy link
Contributor

WeetHet commented Jul 3, 2024

Hi, any updates on when this could be merged and if I can help it to happen sooner somehow?

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 3, 2024
@michaelCTS
Copy link
Author

@WeetHet as per my last comment, there's no time for this on my end. I'm actually going to sell my mac as it's not necessary anymore.

Feel free to branch off my branch and make the changes @toonn wanted (that I disagreed with). It's probably what will get the PR approved.

@michaelCTS michaelCTS closed this Jul 4, 2024
@lrworth lrworth mentioned this pull request Jul 5, 2024
13 tasks
@lrworth
Copy link
Contributor

lrworth commented Jul 5, 2024

I've opened #324701, simplifying this as much as possible in order to get it merged. Someone with more motivation may get something like extract-darwin-app working in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: darwin Running or building packages on Darwin 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Package request: chromium darwin support
6 participants