creativecommons/legaldb

[Bug] LF file endings not enforced for python files

Closed this issue · 3 comments

Description

When setting up the development enviroment for the creativecommons/legaldb repo, I opted to use docker. After all the images were built and the containers start, the db container runs fine, while the app container kept failing and was constantly restarting
Upon further investigation, I discovered that this was caused by the fact that by default, cloning a repo on a windows system using powershell or cmd defaults to CRLF line endings which breaks the server runtime in docker.

Reproduction

  1. Fork the creativecommons/legaldb repo and then clone to your local windows machine using powershell or cmd
  2. Follow the setup instructions as highlighted in the README file of the repo
  3. See error.

Expectation

You would see the following error after following the above steps;

2024-10-07 21:21:00 app-1  | /usr/bin/env: ‘python3\r’: No such file or directory
2024-10-07 21:21:00 app-1  | /usr/bin/env: use -[v]S to pass options in shebang lines

Additional Context

  • Docker, file permissions and line endings: This is an awesome article that describes the behaviour of files copied from a windows machine into a docker volume, to be used in a linux based enviroment. His experience is very similar to what I also experienced. And it doesn't matter if the repo was initially written on a linux machine. This is because of git's behavior which considers the contributor's OS, and then formats the files based on it.
  • Handling line endings in Github: This is the official git documentaion on .gitattributes and how it can be used to handle line endings.

Environment

  • Device: (Laptop)
  • OS: (Windows 11)
  • Browser: (Chrome)
  • Version: (129.0.6668.90)
  • Other info: (docker running on wsl2)

Resolution

  • I would be interested in resolving this bug.

The most concise way of resolving this bug would be including a .gitattributes with an appropriate rule, specifying all python files to have a LF line ending.
A temporary solution for all windows users would be using the git bash terminal (if installed) to clone the repo, but this would need to be explicitly stated in the documentation and is not generally elegant since there is a way to resolve this issue without changing the contributor's experience.

@egbadon-victor have you found good documentation related to this issue or how to resolve it with gitattributes? If so, please add to it to this issue.

@TimidRobot, I have edited my initial comment, including appropriate links to documentation related to this issue. I have also included some comments on the articles

Edit: I also explored tools like dos2unix to convert the files automatically while the containers are being built in docker, but after the following considerations, I decided that it would be less concise and effective.

  1. This will increase the size of the docker image
  2. This would be redundant if the contributor uses a linux machine, hence wasting resources.