-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
[WIP] chromium.withPackages/chromium-extensions: init #98014
base: master
Are you sure you want to change the base?
Conversation
Can you rename uBlock to uBlock origin, so users don't get the two mixed up. |
37918b6
to
e5ce2b5
Compare
Something like this is also especially useful for However, there is at least one problem with using unpacked extensions like this: Each chromium extension has a unique "extension id" like What this means for us is that if there is any change to extension derivation hash in nixpkgs, we'd end up with a different path under It might be possible to patch chromium to generate consistent extension IDs (perhaps by stripping the |
Alternately, would it be an option to symlink extensions into the profile and then pass the consistent profile paths? It looks like it would work as symlinks aren't resolved until after the id is generated, but I'm not very familiar with nix policy on what can go in the profile or how to symlink stuff into the profile. |
Did you have something in mind about what the consistent profile paths could be? I don't think it should be in either the nixos system profile (shouldn't be nixos-specific) or the user profile (since then it depends on the username). (Sorry about inadvertently closing this) |
I'd propose installing it into the same profile chromium is installed into, regardless of whether it's system or user. |
@ryneeverett Sure, but what path do you propose to pass to |
For example: |
I'd still like to be able to build (for example) Also, those paths depend on things that might change, such as the username or the system profile name (see, for example, the (edit: Thanks for the PR by the way. This is definitely a feature I'm interested in as well.) |
I don't necessarily agree with your other points but this one I have no answer to. If a package can exist without a profile then the profile is useless for linking dependencies in this way. |
Just in case it's interesting to you, I've started experimenting with this using the I've also found that the |
I'm thinking the simplest patching approach would be to add an environment variable to the wrapper with a serialized mapping of python/pseudocode: nixmap = json.loads(os.getenv('NIX_CHROMIUM_EXTENSIONS`, ''))
path = nixmap.get(path, path) |
aef2921
to
2f06aee
Compare
Passing a mapping via an environment variable makes a lot of sense. Another option would be a mapping of |
Yes, perhaps it would be more robust to control the id in nix rather than in patched chromium. However I think it would be a slightly more involved patch because
I'm not sure sharing state with webstore-installed extensions by default is desirable. I also don't think it would work out of the box anyway since chromium seems to isolate the storage of local and webstore extension state. I don't foresee any conflicts or security issues though. It also might facilitate sharing state with webstore installations via browser sign-in, but I'm doubtful. Unpacked extensions are designed for development use so I wouldn't be surprised if features like that aren't supported. |
Finally got around to testing a commit patching chromium. It does seem to successfully persist extension id's across extension rebuilds but the state does not persist For the record I did consider patching in the full id (rather than the current approach of using the name within chromium to generate a consistent id) and decided against it. It would basically require implementing the id_util.cc file in nix and I don't see a lot of value in that. Also the |
1dec944
to
d87c066
Compare
Resolve NixOS#76863. This supports the syntax: (chromium.withPackages(ps: [ ps.<extension-package> ])) Upon investigation into the many api's chromium has had for loading extensions over the years, it appears that the only remaining way to load extensions from a local path is by flag which indicates that adding them to the wrapper like this is the only sane option. Chromium's existing plugins.nix already does most of the lifting towards creating the wrapper. This also adds a builder -- buildChromiumExtension -- which basically just requires that the current working directory be the plugin in the installPhase.
As pointed out by @samuelgrf ublock could be confusing and the author is fairly consistent in preferring the ublock origin namespace.
This is an artifact of an earlier revision in which I was going to put a nix-support folder in each extension rather than have a separate chromium-extensions derivation. It was a lot simpler but didn't work because chromium ignores multiple --load-extension flags.
Extension id's are generated from a hash of the extension path. In development this is fine as the extension is updated in place, but as a nix package this would cause state to be lost on every rebuild when the path changes. Therefore we replace the path with the extension's name for the purposes of generating an id.
d87c066
to
2cb61c2
Compare
I marked this as stale due to inactivity. → More info |
Motivation for this change
Resolve #76863.
This supports the syntax:
Upon investigation into the many api's chromium has had for loading
extensions over the years, it appears that the only remaining way to
load extensions from a local path is by flag which indicates that adding
them to the wrapper like this is the only sane option. Chromium's
existing plugins.nix already does most of the lifting towards creating
the wrapper.
This also adds a builder -- buildChromiumExtension -- which basically just
requires that the current working directory be the plugin in the
installPhase.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)Things to do (help wanted)