Isort changing file ownership when running on Docker Container on mounted volume (running as different user from user who owns files)

[dpipemazo]

Our organization uses a shared Docker image to perform standardized code formatting with black and flake8. We can then invoke our formatting configs easily using a command similar to this in any of our repos:

docker run --mount src=$(pwd),target=/code,type=bind elementaryrobotics/formatter

This will mount the current directory into the docker container, and run black, etc. within the container but on the source code on the host. We've been doing this with black for a while now with no issues as black seems to edit files in-place.

After adding isort into the mix we're seeing that the files on our host change their ownership to the root user after they're reformatted using isort in the container. This makes sense as root is the default user in the Docker container. This seems to imply that isort's method for updating files likely involves deletion of the old file and creation of a new file as this would lead to the behavior seen.

Would it be possible to add a mode or update the file writing mechanism in isort to do a truncation/rewrite of the original file as opposed to an operation which would cause the user who is running isort to have the file updated to belong to them? If not perhaps we can note the original owner and set the file ownership of the new file to match the original owner. It would be preferable to have the file ownership not change after running isort.

Thanks for taking a look! Please let me know if I can provide any more info.

[timothycrosley]

Sorry for the delay here! There is now a work around in develop that will make its way out in the 5.8.0 release.
A new flag / config option (--overwrite-in-place/overwrite_in_place) will tell isort to reuse the same file handler instead of swapping it out for the streamed to output file. It hurts performance a bit and consumes extra memory, but it does ensure none of the file info will change.