On Tue, Sep 12, 2017 at 4:56 PM, Robert Schweikert
On 09/12/2017 03:28 PM, Todd Rme wrote:
According to python packaging guidelines, python-based GUI applications should not have the "python-", "python2-", or "python3-" prefix. Ideally this wouldn't be a problem, since these are not dependent on the python version they use. However, a lot of them turn out to be either IDEs (e.g. Spyder), shells (e.g. jupyter's qtconsole or bpython), or other development tools that are dependent on the specific version of python they are built against.
Such packages are hard to use with singlespec macros. One option would simply be to change or not follow the package naming guidelines for such packages. Some packages, such as jupyter, do not follow them, but others like spyder do.
Another option would be to make the macros more useful with such packages. If we go this route, I see four changes that would be extremely helpful in this regard.
First, it would be nice if %python_subpackages allowed us to specify additional packages to manage. These would be packages named using "%package -n foo" that we nevertheless want to have multiple versions of. The macros would then create a set of packages "foo-%{python_bin_suffix}". So for example we might say %{python_subpackages spyder}. If we did that, we would get "spyder-3.6" and "spyder-2.7",
But is that really that useful?
For higher level stuff, even if they put things in site-packages I have started to just simply switch builds to python3. It loads the spec files with if condiftions but SLES 12 is going away in only 7 years ;) and then we'll be rid of Python 2.
Depends on the higher-level stuff in question. For things like IDEs, shells, and debuggers having both python2 and python3 versions is usually essential since they are usually tied to the python version they were built against. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org