https://gradle.com/ logo
Join Slack
Powered by
I wrote about how I'm moving away from `@InputDire...
# self-promotion
m
I wrote about how I'm moving away from 
@InputDirectory
: https://mbonnin.net/2025-01-22_input_directory_is_a_lie/
thank you 2
v
You should reach out to Sophos and complain, our Firewall blocks your page as "Category Gaming" 😄
😄 1
m
Wut??
I mean Gradle can be fun but I wouldn't categorize it as a "game" 😛
v
image.png
🤷‍♂️
m
Thanks for the screenshot! I twitted at them, we'll see
It might be in the hands of your administrators ultimately 🤷
v
The "suggest a different category" goes to a Sophos page where you can send in stuff to be analyzed. 🤷‍♂️
Sure, the admins can for sure manually change the category, but I can also just use mobile or switch on my private VPN 🙂
✅ 1
Btw.
There might be a proper use case for input directories, but I haven’t found one yet. If someone finds one, please reach out!
Reaching out. 🙂 I have a task. This task gets a directory configured. It does not do anything with that directory itself directly, but just passes on the directory to a 3rd party tool. So the property is a 
DirectoryProperty
with 
@InputDirectory
. Or do you see any problems or objections there too?
👀 1
m
I would say there is a 99% chance the tool works on the files inside that directory and not on the directory itself. But it's indeed very common for CLI tools to just take an input directory instead of just passing all the files. In that case, I would do something like so:
Copy code
@get:InputFiles
val sourceFiles: ConfigurableFileCollection

// Absolute path to the base folder containing all the files in sourceFiles
@get:Internal
val root: String
It's a bit more work but it's making it explicit that the tool works on files
v
What would you win with that, or what would work better?
m
If your tool only processes 
*.foo
files, you can add an include pattern to 
sourceFiles
and avoid task reruns if something irrelevant changes inside your directory
It's just more explicit
v
In my case nothing irrelevant is in the directory. I assemble exact needed files in that directory. :-)
For other reasons
In my case the tool is Fop and the directory contains the resources that are referenced in the .fo file
m
For your use case then 
@DirectoryProperty
 
@InputDirectory
is fine but in the grand scheme of things, I'd say the extra overhead and footguns introduced by 
@DirectoryProperty
 `@InputDirectory`is not really worth it.
v
You probably mean 
@InputDirectory
😄
m
Yup, sorry
v
Not using it in this case would be the extra overhead though 😄
m
a few lines of overhead that also has the benefit of teaching the user how input snapshotting works (by snapshotting all the files)
v
Of course all files are snapshotted, what else should be snapshotted for a directory? 🙂
m
This is clear to you, I'm not sure this is clear to everyone
Also, how do you control path sensitivity on an input directory?
v
Nothing is ever clear to everyone 😄
😄 1
m
Copy code
@get:InputDirectory
@get:PathSensitivity(NAME) // Does that apply to the directory path? Or the contents of the directory?
val dir: DirectoryProperty
v
If at all, then on the directory I'd say. The directory is the input you annotate, not the files.
m
So what is Fop doesn't care about the relative local path of the .fo files from their base dir? How do you express that?
v
It's JavaDoc also says task will be out-of-date "if the contents have changed", so the paths of the files inside should always be considered relative to that directory for the snapshotting
So what is Fop doesn't care about the relative local path of the .fo files from their base dir? How do you express that?
That's a big "IF" that hides as "is", because the path is relevant 😄
m
So if you move a file around, your task is now out of date. It technically doesn't need to
v
It does need to
m
Oh sorry, path is relevant
I misread that
v
Well, it would be out-of-date anyway, as the path in the main input - the .fo File - would also have changed in this case
m
The contents you mean?
(sorry, not familiar at all with how .fo files work)
v
Two inputs, a RegularFileProperty that has the .fo file which references files from that directory the DirectoryProperty that contains the referenced and up-front collected files referenced in the .fo file.
Fop then gets the .fo file and the directory as basedir and makes a PDF out of the .fo file
So if anything in the paths in the dir changed, the content of the .fo file also changed and the task would be out-of-date anyway
m
👍
All in all, 
@InputDirectory
saves you a few lines because you satisfy all the conditions (all the files in the input are used and their relative path is used as well). In terms of API design, I still believe it's a bit of a niche API that is easy to misuse and adds mental load for no real benefit. The same thing can be achieved with 
@ConfigurableFileCollection
.
Ideally, I'd like an API in 
ConfigurableFileCollection
to determine if it is "rooted". This would remove the need for 
@Internal
completely
v
🤷‍♂️ 😊
😄 1
Just wanted to tell you as you asked for valid use-cases in the post and I just stumbled over my class 🙂
m
🙂 Thanks for the discussion, I'll add some comments to the post!
👌 1
3 Views
Open in Slack
PreviousNext
Powered by