On Mon, Oct 31, 2016 at 11:28 AM, jan matejek
hello,
On 27.10.2016 20:35, Todd Rme wrote:
2. Along those lines, I think pypy2 and pyp3 versions should be available, especially with a lot of progress now happening in pypy3 thanks to mozilla funding it.
I would very much prefer to NOT support pypy 2 at all, now that pypy3 is making significant progress. Given that we don't really support pypy2 at this point, I don't see any benefits in starting.
Fair enough, but I still think keeping things consistent would be preferable. So even if there is no "pypy2" commands, I think we should still call iot "pypy3" to maintain the same pattern.
That's why my proposal uses unversioned "pypy". That is not going to be future-proof if we ever get pypy 4, but, well, I say we take that risk ;)
We are getting about 1 python minor version a year, with 3.6 coming out any time now. Guido has said he that python 4 will just be python 3.10 because he doesn't like double-digit versions. This means we are probably about 4 years away from Python 4. So I would include the python 4 transition in any plans we make, it isn't far off at all. In fact it will probably happen about the same time as 2.7 is EOL.
I would personally keep dlp as a generic place for all python packages. This has worked very well up to this point and I don't see any advantage to changing it.
I have always considered d:l:py to be a generic place for Python modules and tools -- that is, for software where Python is a fundamental property, as opposed to implementation detail. From your conversation with Simon, it doesn't seem like you disagree on this, but you're concerned about the "edge case" packages -- where it's unclear whether the "library" or the "utility" part is more important.
Let me clarify that I don't propose to throw these out summarily. I'm more concerned about the actually-clear-cut apps. I don't know how many of those are in d:l:py now, but I have rejected several in the last year, and I'd like to make it clearer that these don't belong. (Also, being more careful about the edge cases would not hurt, IMHO ;) )
Agreed. My point is that we need to be very clear about this policy. The current python application naming policy is pretty fuzzy and I don't think it handles these "edge" cases well (scare quotes because they are by far the most common case).
I think the rule should be that if the executable is intended for use with python files or packages, it should provide both python 2 and python 3 versions when available.
to this I would add, "and if the executable doesn't natively support multiple python versions". For instance, if pylint3 could work on python 2 by itself, I would include it in the rule and say that we will only distribute pylint3. This could very well be the case for IDEs and similar.
Agreed. Although IDEs are a problem because the python shell they support is usually the same as they python version they were built against.
Finally, three, d:l:py is collecting non-python dependencies of python modules. That should not be happening. Analogously to point one, policy proposal: If your package depends on something that is not appropriate for d:l:py, either get that dependency into Factory, or your package is also not appropriate for d:l:py.
A lot of these are backports for older versions of openSUSE that either have outdated versions of the library or lack the library entirely. So yes, I agree if it really has non-Factory dependencies it probably shouldn't be there. But I think the bigger problem is that many of these are (or were) needed but are building for openSUSE
It doesn't make sense to me to build a binding for, say, 13.2, for a library that is not present or too old in 13.2. In such case, I think the right solution is to disable build for the older SUSE version -- and optionally link the binding to a project that provides the newer library for the older distribution.
What about, say, a general-purpose numerical library that needs some C library to do some task? What about an update to a key existing program that gets a new indirect C dependency?
2. Package naming. Might this be a chance to switch from using python-foo to python2-foo? Either way, I would strongly suggest pypy packages using pypy2-foo and pypy3-foo from the beginning, rather than pypy-foo.
Probably not, for technical reasons. The problem is that the macroset can't modify what's already explicitly written in the spec file. So if the spec is for python-foo, and has a %files section, then we MUST build package python-foo that includes the files listed.
Can't you have the macros based off, say "%files -n python%{default_py_ver}-foo" or something like that and have no %files section? I would very much prefer no version number in the .spec file. With python 4 likely very close, I think it would be better to be prepared for this now rather than having to do this all over again before too much longer.
3. Version-specific packages. There are still a lot of packages that only support python 2, and an increasing number that only support python 3. Should these use the macros or be kept simple?
python2-only, I would consider legacy and keep simple, until such a time when they move to python 3
python3-only, I'd use the macros and "%define have_python2 0". After all, these could work on pypy or other flavors that might be created in the future.
Sound reasonable. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org