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

dream.lock: injecting existing dependency #244

Closed
wmertens opened this issue Aug 11, 2022 · 3 comments
Closed

dream.lock: injecting existing dependency #244

wmertens opened this issue Aug 11, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@wmertens
Copy link
Contributor

wmertens commented Aug 11, 2022

To fix packages that don't specify all their dependencies, it would be nice to have access to the dependencies so that you could do something like

dependencies: let
  getPkg = name: let version = elemAt 0 (attrNames dependencies.${name}); in { inherit name version; };
  missingDep = getPkg "foo";
  broken = getPkg "broken";
  brokenDeps = oldDeps.${broken.name}.${broken.version};
in
  dependencies // { ${broken.name}.${broken.version} = brokenDeps ++ [missingDep]; }

So then first the translator runs and then the dependencies can be patched before the cycle detection.

That way you can use the translator to determine the package details by adding the missing dep to the root dependencies and letting the translator resolve the impurity.

This could also be used to force using a certain version of a package etc.

For even more flexibility, the sources could also be passed into the function (or to a separate function) so they can be patched too.

@wmertens
Copy link
Contributor Author

It would also be great if this could be integrated with the overrides system. So then a known-broken package can always have the correct dependency injected.

Or maybe that is already possible?

@DavHau
Copy link
Member

DavHau commented Aug 13, 2022

Currently the way to inject dependencies manually is using the inject parameter as seen in the example of the main readme.
This is currently injected at evaluation time after translation. This will work with any translator and does not need to be supported by a translator.

Also for some translators, it is possible to add extra dependencies via argument. For example the pip translator allows specifying extraSetupDeps.

We do not have a way of adding deps via the override system so far. Maybe this could be integrated better. But I think first, we should have a proper module system in place before extending the current hacky API any more.

There were some discussions here: #156
And I recently opened a PR to move functionality to nixos modules: #249

@DavHau DavHau added the enhancement New feature or request label Aug 13, 2022
@DavHau
Copy link
Member

DavHau commented Nov 9, 2022

Closing as injecting existing dependencies is already possible.
There are issues tracking improvements: #361
If there are some other specific things we need to improve, let's open a specific issue for that

@DavHau DavHau closed this as completed Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants