rapids-dependency-file-generator attempts to update yaml files in build directories

[dagardner-nv]

I switch between bare-metal builds and performing builds inside Docker.

This can lead to permission errors when the build directory is a build artifact from Docker and is owned by root. Resulting unexpected permission errors.

Is it possible to optionally disable this with a --no-explore flag?

[jameslamb]

Is it possible to optionally disable this with a --no-explore flag?

What are you asking for that flag to do? To not update files in place?

Also is --no-explore a reference to some other CLI? To me, that name doesn't imply the behavior "do not update any files in place". Maybe --dry-run would better capture what you're looking for?

[dagardner-nv]

Is it possible to optionally disable this with a --no-explore flag?

What are you asking for that flag to do? To not update files in place?

Also is --no-explore a reference to some other CLI? To me, that name doesn't imply the behavior "do not update any files in place". Maybe --dry-run would better capture what you're looking for?

I want rapids-dependency-file-generator to update the conda files under the conda/environments directory, but not those yaml files which have been installed into the build directory.

[gforsyth]

One option (although it will likely introduce an extra dependency on the CLI) is to have rapids-dependency-file-generator respect .gitignore and not touch any files in the ignored directories.

[jameslamb]

but not those yaml files which have been installed into the build directory.

I'm sorry, I still do not understand this use case and what's being requested here.

If you don't want rapids-dependency-file-generator touching files in "the build directory", why are you running it there?

[vyasr]

I think you can work around the current problem by specifying some arguments to the CLI (i.e. the location of dependencies.yaml) and then running the tool from a different directory to avoid it descending into the build directory, but that may not be the most ergonomic. It's not clear exactly what should be changed, though, so I agree with James that more information is needed regarding exactly what is being requested.