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

feat: support managing submodules via inputs.self #7862

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tomberek
Copy link
Contributor

@tomberek tomberek commented Feb 19, 2023

Provides special handling for inputs.self. If submodule is set to true, will re-call getFlake as if the original reference was set. The intended behavior is for CLI management of the parameter overrides any direct flake.nix settings.

Thanks to: @x10an14, @aaronchall, @mrene

Motivation

Context

Provides a mechanism for inputs.self.submodules to control the availability of submodules in a local flake.

Checklist for maintainers

  • test with remote resources (@Kranzes)
  • provide check/error for that this logic won't work with "github:"

Maintainers: tick if completed or explain if not relevant

  • agreed on idea
  • agreed on implementation strategy
  • tests, as appropriate
    • functional tests - tests/**.sh
    • unit tests - src/*/tests
    • integration tests - tests/nixos/*
  • documentation in the manual
  • code and comments are self-explanatory
  • commit message explains why the change was made
  • new feature or incompatible change: updated release notes

Provides special handling for inputs.self. If submodule is set to true,
will re-call getFlake as if the original reference was set. The intended
behavior is for CLI management of the parameter overrides any
direct flake.nix settings.
Comment on lines +238 to +240
if (originalRef.input.attrs.count("submodules") == 0) {
auto self = flake.inputs.find("self");
if (self != flake.inputs.end() && self->second.hasSubmodules) {
Copy link
Member

Choose a reason for hiding this comment

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

This comparison is a little ad hoc. It should be described in more general terms. My understanding of the process is:

  1. Nix makes a guess what the self input is
  2. Nix checks that its guess matches the declared self input
  3. Adjust

None of this is specific to git or submodules, so it should be done through virtual methods.

Other than that, I think lazy trees #6530 should make this specific parameter conceptually redundant, and enable it by default, as submodules should be fetched lazily.
However, that's not a reason not to have this mechanism, as we'll need it for at least a git-crypt parameter.

Copy link
Member

Choose a reason for hiding this comment

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

A general mechanism (but also with submodules as the motivating case) is described and discussed in

@@ -114,6 +114,8 @@ reference types:

* `ref`: A Git or Mercurial branch or tag name.

* `submodules`: A boolean supporting Git submodules.
Copy link
Member

Choose a reason for hiding this comment

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

What's the default?

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
* `submodules`: A boolean supporting Git submodules.
* `submodules`: Whether to also include Git submodules. Defaults to `false`.

@@ -405,6 +421,7 @@ LockedFlake lockFlake(
necessary (i.e. if they're new or the flakeref changed
from what's in the lock file). */
for (auto & [id, input2] : flakeInputs) {
if (id == "self") continue;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Needs a note, and docs, about the “self” input being special.

@edolstra
Copy link
Member

Hm, it seems pretty ugly to add a git-specific submodules field to inputs.self. IMHO the better solution would be to enable submodules by default (after we've implemented efficient submodules support on the lazy-trees branch).

@Kranzes
Copy link
Member

Kranzes commented Feb 20, 2023

Hm, it seems pretty ugly to add a git-specific submodules field to inputs.self. IMHO the better solution would be to enable submodules by default (after we've implemented efficient submodules support on the lazy-trees branch).

Yeah it isn't fancy. We just implemented it overnight in a call yesterday. We're not even sure if this is even a good idea to have. The thing is that the git-specific submodules inputs field already exists, it's just take effect in the CLI. That's what this PR does, it makes it function as you expect. This isn't an addition of a new feature, it is a fix of an already existing functionality.

@tomberek tomberek marked this pull request as draft February 21, 2023 01:38
@fricklerhandwerk
Copy link
Contributor

fricklerhandwerk commented Feb 24, 2023

Triaged in the Nix team meeting:

  • @edolstra: prefer to enable submodules by default
    • right now they are extremly inefficient, but may want to make it work with lazy trees
  • @thufschmitt: wouldn't hurt to have a feature to forcibly enable them
    • @edolstra: this would change the flake language, requires us to continue supporting this eventually
  • @tomberek: often in practice people use submodule for private dependencies
  • @fricklerhandwerk: how high on our global priority list is this?
  • to discuss

@Kranzes
Copy link
Member

Kranzes commented Feb 24, 2023

@edolstra: prefer to enable submodules by default

I believe that used to be the case but it was reverted because it was fetching when people didn't want it.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-02-24-nix-team-meeting-minutes-35/25757/1

@Kha
Copy link
Contributor

Kha commented Feb 24, 2023

@edolstra: prefer to enable submodules by default

I believe that used to be the case but it was reverted because it was fetching when people didn't want it.

To be clear it was because of their inefficiency #5280. But that sounds like a perfect application of lazy trees as mentioned.

@thufschmitt thufschmitt added feature Feature request or proposal flakes labels Feb 27, 2023
@JakeHillion
Copy link

JakeHillion commented Mar 18, 2023

To chime in, I've seen C++ projects before where certain submodules are optional except for special cases like testing. While enabling by default would be helpful, I can also imagine a feature like .?submodules=extern/X,extern/Y being useful to keep clones efficient. This wouldn't fit neatly with always including submodules. I don't know how this fits in with flakes though as generally you'd want the flake to cover every case (incl. testing) so it may be very niche, or be on a per output level.

Either way, this feature as implemented in this PR or submodules by default would be incredibly useful for me.

@roberth
Copy link
Member

roberth commented Mar 18, 2023

I think we should consider closing this, because the non-libgit fetching has too many problems and a more elegant replacement is in progress in #6530.
We'd better make some progress on that, because we should neither develop a dead end, nor let fetcher development be blocked for a year.

@fricklerhandwerk
Copy link
Contributor

Discussed in the Nix team meeting:

We recommend instead to build a Nix language function that re-fetches an input by adding ?submodules=true. This is dirty but avoids changing Nix itself.
We plan on delivering a principled solution eventually anyway, and the soft implementation is a good-enough stopgap.

Complete discussion
  • @Ericson2314: it would make sense if we implemented libgit first
  • @roberth: it's a good mechanism, but we don't have a need for it yet
  • @edolstra: the real problem is that it changes the interface by adding inputs.self, and we'd have to continue supporting that in the future
    • especially if it hardcodes submodules default to false
    • @thufschmitt: don't think the default is a problem
    • @fricklerhandwerk: is anything speaking against treating that addition as "extra-experimental" in isolation, even if we currently have no means of expressing it in the code?
      • @thufschmitt: that's the problem, there is no way of enforcing it whatsoever
      • @edolstra: in principle since flakes are experimental, we can change it arbitrarily, but ideally we shouldn't have to change the interface if it can be avoided
  • @thufschmitt: since submodules is false by default, one would have to specify the parameter to build the top-level flakes every time
    • would it make sense set it true for the top-level flake by default?
    • @edolstra: no, that would be very expensive
  • @edolstra: it's convenient to the user, but architecturally questionable to do the double-fetching
    • @roberth: with lazy trees this will become super cheap
  • @thufschmitt: couldn't we instead build a Nix language function that re-fetches an input by adding ?submodules=true?
    • this is dirty but avoids changing Nix itself
    • we will deliver a principled solution eventually, and this is good enough as a stopgap
  • decision: postponed

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-20-nix-team-meeting-minutes-42/26615/1

@NorfairKing
Copy link

NorfairKing commented Jan 24, 2024

What's the status here? I'd really like not to have to specify ?submodules=1 on the command-line every time.

@roberth
Copy link
Member

roberth commented Jan 24, 2024

fetchTree will fetch submodules lazily in the upcoming release, 2.20.
We'll have very little reason to disable submodules by default...

EDIT: added to team discussion queue for Friday.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/get-nix-flake-to-include-git-submodule/30324/13

@amfaber
Copy link

amfaber commented Mar 27, 2024

Is this available on nix version 2.20 onwards? I would very much like an example of how I can build a derivation using a local submodule

@znd4
Copy link

znd4 commented Mar 28, 2024

@amfaber , not a contributor/maintainer, but it doesn't seem like it based on the release notes

@roberth
Copy link
Member

roberth commented Mar 28, 2024

Is this available on nix version 2.20 onwards?

It is not.

We'll have very little reason to disable submodules by default...

We're still exploring the solution space for efficiently fetching from a forge such as GitHub, which can return a tarball as a significantly quicker operation, so it's hard to tell whether changing the default setting would make sense.

I do think we'll need a configurable inputs.self regardless.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/get-nix-flake-to-include-git-submodule/30324/14

@jakubgs
Copy link

jakubgs commented Mar 30, 2024

Lack of support for submodules for current(self) repo makes packaging most of our software not viable using Nix Flakes.
I'm really hoping we can get support of submodules for self in Nix.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/handling-git-submodules-in-flakes-from-nix-2-18-to-2-22-nar-hash-mismatch-issues/45118/1

sjmonson added a commit to sjmonson/tdr-inverse that referenced this pull request May 23, 2024
Must be built with `nix build '.?submodules=1'` until this is merged:
  NixOS/nix#7862
@AshleyYakeley
Copy link

Any update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature request or proposal flakes
Projects
Status: ⚖ To discuss
Development

Successfully merging this pull request may close these issues.