search

ofek / userpath

Cross-platform tool for adding locations to the user PATH, no elevated privileges required!
MIT License
151 stars 20 forks source link

README.rst EOL #2

Closed frenzymadness closed 6 years ago

frenzymadness commented 6 years ago

Hi.

I have a strange problem with the README.rst end of lines. I found out it during package review for Fedora with the following error from RPMLlint:

W: wrong-file-end-of-line-encoding
/usr/share/doc/python2-adduserpath/README.rst

The strange fact is that when I clone this repository and try to fix EOL with dos2unix nothing happens because the file contains right EOLs but when I try the same thing with tarball from PyPI EOLs are converted.

Cloned from github:

$ dos2unix -v README.rst
dos2unix: Converted 0 out of 96 line breaks.
dos2unix: converting file README.rst to Unix format...

Downloaded from PyPI:

$ dos2unix -v README.rst
dos2unix: Converted 96 out of 96 line breaks.
dos2unix: converting file README.rst to Unix format...

I can fix it by myself during a build of RPM but I think that it would be better to have Unix EOLs everywhere.

ofek commented 6 years ago

That's unexpected behavior. Here is how it is read (notice the from io import open):

https://github.com/ofek/userpath/blob/14c25ca4062898d0a5b3aa5d6ffbf69b2d91944e/setup.py#L13-L14

Docs say:

open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)
...
newline controls how universal newlines works (it only applies to text
mode). It can be None, '', '\n', '\r', and '\r\n'.  It works as       
follows:                                                              

* On input, if newline is None, universal newlines mode is            
  enabled. Lines in the input can end in '\n', '\r', or '\r\n', and   
  these are translated into '\n' before being returned to the         
  caller. If it is '', universal newline mode is enabled, but line    
  endings are returned to the caller untranslated. If it has any of   
  the other legal values, input lines are only terminated by the given
  string, and the line ending is returned to the caller untranslated. 
...

So \n should be what is returned. Do you agree?

frenzymadness commented 6 years ago

I don't think it has something related to reading README.rst file to package description. Moreover, it seems that it's not a problem only with readme. I downloaded/cloned source code from PyPI and git to separated folders and ...

$ md5sum git/README.rst pypi/README.rst
523ebe4a748c7a4e07c68e569f600e3f  git/README.rst
f7699c4df99d7d234422e0aba4f66de5  pypi/README.rst
$ file */README.rst
git/README.rst:  ASCII text
pypi/README.rst: ASCII text, with CRLF line terminators
$ file */MANIFEST.in
git/MANIFEST.in:  ASCII text
pypi/MANIFEST.in: ASCII text, with CRLF line terminators
$ file */LICENSE-MIT
git/LICENSE-MIT:  ASCII text
pypi/LICENSE-MIT: ASCII text, with CRLF line terminators
$ file */setup.py
git/setup.py:  Python script, ASCII text executable
pypi/setup.py: Python script, ASCII text executable, with CRLF line terminators

Maybe something happened during development but I cannot find this change in git history. Furthermore, it seems that PyPI contains the newest files because the last commit is the move to version 0.4.0. Do you do something unusual with files during a new release?

It is really weird.

ofek commented 6 years ago

I mean, I use Windows, but that doesn't explain it since git gets it right.

ofek commented 6 years ago

Fixed in future releases. Thanks for bringing this to my attention!

ofek commented 6 years ago

Fixed for all projects, fyi.

frenzymadness commented 6 years ago

Could you explain to me how this happened? Just for a case, I would meet this situation again.

ofek commented 6 years ago

I dev on Windows and therefore PyCharm defaulted to CRLF. However, I never detected this because git was converting line endings to LF.