| 15 Sep 2025 |
raitobezarius | it should only pass it to a git fetcher | 18:37:07 |
laurents | I'm wondering if git+file:// could work | 18:37:34 |
raitobezarius | static std::set<std::string> allowedAttrs{"submodules"};
auto newRef(ref);
for (auto & attr : *flake.selfAttrs) {
if (!allowedAttrs.contains(attr.first)) {
throw Error("flake 'self' attribute '%s' is not supported", attr.first);
}
newRef.input.attrs.insert_or_assign(attr.first, attr.second);
}
if (newRef != ref) {
return newRef;
}
| 18:38:16 |
raitobezarius | this is the piece of code that is wrong | 18:38:19 |
raitobezarius | nwRef.input.attrs.insert_or_assign should NOT happen if the input DOES NOT support submodules | 18:38:36 |
raitobezarius | and… probably a warning should be emitted to tell you "hey, you are using a fetcher that doesn't support automatically retrieving submodules, this is fine but if you forget to do it, things could not work" | 18:39:06 |
raitobezarius | newRef.input.scheme should be the variable you should use to gate this assign | 18:39:38 |
raitobezarius | newRef.input.scheme == "git" probably | 18:39:43 |
raitobezarius | that being said, not using flakes here would probably be very hard if you want to keep the input.follows behavior | 18:40:28 |
raitobezarius | basically, we need flakes-compat to support the follows system | 18:40:49 |
raitobezarius | and then you wouldn't have to deal with this | 18:40:55 |
raitobezarius | but you'd lose all the flakes CLI | 18:41:03 |
raitobezarius | let's just fix that bug I'd say | 18:41:08 |
laurents | so git+file:// instead of path:// fixes it :) | 18:41:26 |
raitobezarius | great :) | 19:02:39 |
raitobezarius | I still think some warning to recommend git+file:// is relevant | 19:03:21 |
laurents | I'll see if I can work out all the layers of stuff I have to learn to fix that piece of code | 19:03:37 |
laurents | but yes, I agree that a nice warning would be better | 19:04:00 |
raitobezarius | perhaps if (newRef.input.scheme != "git") { warn("You are using blablablabla"); } as an addition would be sufficient | 19:09:16 |
raitobezarius | (and a test) | 19:09:20 |
laurents | dumb question (again), but I'm trying to redo what you did above, replacing the github: ref with a git+https:// and I keep getting git errors, did you change anything else to make it work? | 19:26:08 |
raitobezarius | i had to modify manually the flake.lock | 20:04:51 |
raitobezarius | because if you go from the one you had, it's already broken | 20:04:57 |
raitobezarius | so i nuked all the entries regarding your input | 20:05:04 |
raitobezarius | and re-inserted it | 20:05:06 |
| 16 Sep 2025 |
| -> @oli:catgirl.cloud changed their profile picture. | 06:59:57 |
| -> @oli:catgirl.cloud changed their profile picture. | 09:04:49 |
laurents | well well, it looks like using a git+https://github.com/some/repo input does not work if said repo is a fork. If I clone the repo, and create a new one on github that is not a fork, say git+https://github.com/some/repo_that_is_not_a_fork, then lix is happy to use it as an input. | 12:27:03 |
raitobezarius | absolutely unhinged bug | 12:57:28 |
laurents | ok, apologies, ignore me, somehow the nix cache got into an invalid state. once I removed it, the fork version worked again. I'm not sure how it got into that broken state, but I think I will leave it at that for now. Sorry for the noise. | 13:27:00 |