search

LittleDevMars / pyftpdlib

Automatically exported from code.google.com/p/pyftpdlib
Other
0 stars 0 forks source link

__ver__ is not a convention #278

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1. >>> import pyftpdlib
2. >>> pyftpdlib.__version__
AttributeError: 'module' object has no attribute '__version__'

__ver__ is very uncommon for Python packages. It would be nice if pyftpdlib 
provided common __version__ field.

I'd add alias myself, but I am not sure what is the current backward 
compatibility practice. If we decide to remove __ver__ at some point, how do we 
find it? Or we just keep everything?

Original issue reported on code.google.com by techtonik@gmail.com on 19 Jan 2014 at 11:27

GoogleCodeExporter commented 9 years ago 
Mmmm are you really sure the most used convention is __version__ and not 
__ver__ (I seem to recall the contrary)?
Not that it really matters anyway because as you also point out it is too late 
as the change would not be retro compatible (__ver__ has been there for years 
now).

Original comment by g.rodola on 19 Jan 2014 at 11:42

GoogleCodeExporter commented 9 years ago 
...also I don't think adding a __version__ alias would add any value. It would 
only cause more confusion. 
I'm going to close this out as rejected.

Original comment by g.rodola on 19 Jan 2014 at 11:49

GoogleCodeExporter commented 9 years ago 
Ok. Let's check.

>>> import sphinx
>>> sphinx.__version__
'1.1.3'

>>> import pip
>>> pip.__version__
'1.4.1'

Your turn. =)

Original comment by techtonik@gmail.com on 19 Jan 2014 at 12:29

GoogleCodeExporter commented 9 years ago 
Ok, but as I said, it's too late: checking for version at runtime only works if 
both old and new versions of the module you depend from provide the same API.
I see little value in adding __version__ in 1.3.1 but not having it in <= 1.3.0.
Whoever wants to take decisions based on pyftpdlib version will likely grep for 
"__ver", and eventually find it and use it, no matter what the recommended 
convention is.  I see your point though: I'm only talking about practical 
reasons here.

Original comment by g.rodola on 19 Jan 2014 at 12:43

GoogleCodeExporter commented 9 years ago 
There is a lot of value if your package requires pyftpdlib > 1.3.0, so I am for 
adding __version__ field and provide __ver__ alias for backward compatibility.

__version__ is not in PEP probably, but I use it for automation. Here you can 
see automated setup.py generation - https://bitbucket.org/techtonik/astdump/ 
and it is only a proof of concept, which can be extended to automatic package 
generation not only for PyPI, but also for Ubuntu and other distributions.

Original comment by techtonik@gmail.com on 19 Jan 2014 at 12:52

GoogleCodeExporter commented 9 years ago 
Closing this out as won't fix.

Original comment by g.rodola on 11 Apr 2014 at 9:24

GoogleCodeExporter commented 9 years ago 
But why? It doesn't break anything and add consistency with other packages.

Original comment by techtonik@gmail.com on 12 Apr 2014 at 2:00

GoogleCodeExporter commented 9 years ago 
I explained why in comment #4.

Original comment by g.rodola on 12 Apr 2014 at 9:14

GoogleCodeExporter commented 9 years ago 
> it's too late: checking for version at runtime only works if both old and new
> versions of the module you depend from provide the same API.

Yes, my requirement.txt contains pyftpdlib > x.x.x, so it is never too late to 
add new API that doesn't break anything existing.

> hoever wants to take decisions based on pyftpdlib version will likely grep
> for "__ver"

1% likely is a bad user experience design, and it is not practical at all for 
tools that need to run checks on code that is compatible with common human 
conventions.

Original comment by techtonik@gmail.com on 14 Apr 2014 at 9:25

GoogleCodeExporter commented 9 years ago 
I don't have an opinion either way on this (I've not needed to read the version 
number directly), but a quick google throws up 
http://stackoverflow.com/questions/458550/standard-way-to-embed-version-into-pyt
hon-package which seems to confirm that there's common conventions of using 
__version__, but no 'proper standard'.

6 of one, half a dozen of the other ;-)

Original comment by gc...@loowis.durge.org on 14 Apr 2014 at 11:20

GoogleCodeExporter commented 9 years ago 
Upvoted SO. =)

Original comment by techtonik@gmail.com on 14 Apr 2014 at 11:28