Conversation
|
I'm wondering if this will still be necessary with #264891 🤔 |
|
Definitely is IMO. Not everything is or should be a git repository. |
|
Another reason I can't switch from sources to filesets yet: I want to be able to do, essentially: |
There was a problem hiding this comment.
That's a really valuable addition to the library, as you said because it would ease migration a lot. We may want to note that in the docstring, along the lines of
use this to gradually migrate builds relying on
lib.sourcestolib.fileset
but that's no reason to block this PR.
PS: Not sure why it's still in draft mode, looks ready to me.
lib/fileset/default.nix
Outdated
There was a problem hiding this comment.
What's a source-like value? What's a source?
There was a problem hiding this comment.
"Very" good question unfortunately. Basically a path value or the "source attrset" returned by the lib.sources functions. Can we write introductions for sublibraries yet? It'd be great to have a sensible place to document the unique types of each sublibrary.
There was a problem hiding this comment.
Can we write introductions for sublibraries yet?
lib/fileset/default.nix
Outdated
There was a problem hiding this comment.
The example in the PR description is also relevant, because it shows a bit of integration.
There was a problem hiding this comment.
Added some more practical examples now
roberth
left a comment
There was a problem hiding this comment.
Remember to test that directories for which the predicate is false are not read. This is part of the (implicit) contract.
Other than that, I think the tests will "write themselves" if that makes sense.
lib/fileset/default.nix
Outdated
There was a problem hiding this comment.
This doesn't seem to actually take SourceLike (although I didn't define that in words in lib.sources, you could perhaps tell from the code or behavior).
That type was meant to cover all source-coercible types, similar to how you allow both paths and filesets as arguments to fileset functions. In fact, it seems to be pretty much exactly that.
So what I meant to say is lib.sources users will probably expect to be able to use any source here, whether that's an _isLibCleanSourceWith, or a path value. Rejecting path values makes libraries (e.g. lang2nix) that use this fragile.
Not simplifying fromSource ./. to ./. is harmless, while { src, ... }: f (fromSource src) would be a bug waiting to happen.
See the checklist in the PR description 🙂. Generally I recommend not taking close looks at the code of draft PRs. If I request you for a review it's because I'd like feedback to the approach only. I'll mark PRs as ready to review when I think their implementation is ready to review. The review comments you both left are very helpful though, will incorporate! |
4133f7a to
3dfaf15
Compare
It didn't make sense to me, but I wrote tests anyways and pushed them now :) Still need to clean up the code and docs a bit, including addressing the review comments. I'll mark it as ready when everything is addressed. |
3dfaf15 to
7349358
Compare
roberth
left a comment
There was a problem hiding this comment.
One question; otherwise lgtm.
| throw '' | ||
| lib.fileset.toSource: `root` is a `lib.sources`-based value, but it should be a path instead. | ||
| To use a `lib.sources`-based value, convert it to a file set using `lib.fileset.fromSource` and pass it as `fileset`. | ||
| Note that this only works for sources created from paths.'' |
There was a problem hiding this comment.
Any reason not to just call it for them?
There was a problem hiding this comment.
I'm not 100% convinced it's a good idea, just minor ideas like
- The operation this function does is somewhat expensive, so it being explicit makes people aware of that. This is different from the implicit path coercion, which is very cheap
- Do we want to deprecate this at some point? Probably not
- Source filters can be impure by changing behavior based on the project directory, does this impurity leak into file sets? Probably not a problem
- Is it a problem to have a lack of symmetry regarding
toSource/fromSource? Probably not, these aren't symmetric, fromSource discard's therootandtoSourcehas to add it - Would it be a problem to have cases like
toSource { root = ./.; fileset = toSource { root = ./.; fileset = toSource { ...? Probably also no
Furthermore this being an error for now means that we could still do this later.
Description of changes
Another split off from #222981, motivated by @alyssais's comment here. This introduces one new function:
lib.fileset.fromSource: Create a file set from a filtered local source as produced by thelib.sourcesfunctions.This is mainly useful for migration from
lib.sources-based filtering. In the future we should have a convenience function inlib.filesetthat could take over.This work is sponsored by Antithesis ✨
Things done