[opensuse-packaging] python singlespec: how to convert your package

Dear packagers, this is an overview of how singlespec works and how to use it for your package. First, some key concepts: * It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py. * It is designed to work on specs called "python-something". There is some support for "python2-something" and "python3-something", but it is mostly untested. If your spec file name doesn't start with "python", don't even try. (Yet.) * (if you're building for Factory,) all your dependencies must be converted first. That's because the macros will BuildRequire "python2-things", which only exist for packages that are already converted. The devel:languages:python:singlespec already has basic packages, and not all of them will be in d:l:py immediately, so if you want to play now, build against this project. I'll also be accepting SRs into it. * In general, if you're unsure, please submit to d:l:py:singlespec first. Also examine linkdiffs of packages in d:l:py:singlespec to get an idea of how it can look like. https://build.opensuse.org/project/show/devel:languages:python:singlespec * Individual macros are documented on github https://github.com/openSUSE/python-rpm-macros * I'm working on an autoconverter that performs most of the following steps automatically. I intend to use it to convert most of d:l:py into d:l:py:singlespec:staging, and then review and submit packages one by one. So maybe if you wait, you can save yourself some work ;) Conversion steps: 0. If you want to build for anything other than Factory, you need to include compatibility shims. This definition of the %python_module macro goes on top of your spec: %{?!python_module:%define python_module() python-%1 python3-%1} and a buildrequire: BuildRequires: python-rpm-macros 1. Wrap all your "BuildRequires: python-something": BuildRequires: %{python_module something} Do not do this in Requires or any other fields. If you have a buildrequire that should only apply to one python, say, python-enum34 only for python 2, do not wrap it. 2. At the end of the spec preamble, before %description, place the macro: %python_subpackages on a line by itself 3. Replace "python setup.py build" with %python_build and "python setup.py install" with %python_install. These already contain the usual arguments (--prefix, --root), so usually you don't need to add any. If you configure CFLAGS or something like that, export them first: CFLAGS="-fwrapv" python setup.py build -> export CFLAGS="-fwrapv" %python_build If you are running any other commands based on python, use %python_exec. "python setup.py test" -> "%python_exec setup.py test" This works for usual test runners too: "nosetests" -> "%python_exec %{_bindir}/nosetests" 4. If you're doing something more complicated ... say, removing files from %python2_sitelib and %python3_sitelib, use %python_expand. "%python_expand rm -f %{$python_sitelib}/foo/undesirable.txt" Yes, that is "%$python_sitelib". Beware. If you put only "%python_sitelib", it will not work, because "%python_sitelib" gets expanded before %python_expand touches it. In general, after %python_expand, "$python" is replaced by all pythons even in macro names. If you need more lines, wrap in braces: %{python_expand firstline secondline $python thirdline} Note that the first line must not be empty. 5. change "%files" to "%files %{python_files}" If you have subpackages, say "%files foo", then change to "%files %{python_files foo}". 6. If some files are only in one python version, mark them as %python2_only or %python3_only in the filelist. If there's more of them, you can use %ifpython2 ... %endif If the entry in question is a __pycache__ directory, use %pycache_only or %ifpycache. 7. If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.) (If you are sure that you need executables for all python versions, look at what python-bottle does: https://build.opensuse.org/package/view_file/devel:languages:python:singlesp... note the installation inside %python_expand. Usually, packages don't install versioned executables by themselves, so you need to do it manually. If your package does, good for you.) 8. Take the time to enable automatic tests :) have a nice weekend m.

On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- Individual macros are documented on github https://github.com/openSUSE/python-rpm-macros
As this now becomes 'law' for the openSUSE packaging: can you please ensure that the openSUSE wiki reflects the method of singlespec, giving guidance on the whole thing? This is quite important for users as well as for the review team to have clear info on what must be, what should be and what must not be present. Thanks, Dominique

On Fri, Feb 17, 2017 at 12:31 PM, jan matejek <jmatejek@suse.com> wrote:
Dear packagers,
this is an overview of how singlespec works and how to use it for your package. First, some key concepts:
It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py.
It is designed to work on specs called "python-something". There is some support for "python2-something" and "python3-something", but it is mostly untested. If your spec file name doesn't start with "python", don't even try. (Yet.)
(if you're building for Factory,) all your dependencies must be converted first. That's because the macros will BuildRequire "python2-things", which only exist for packages that are already converted. The devel:languages:python:singlespec already has basic packages, and not all of them will be in d:l:py immediately, so if you want to play now, build against this project. I'll also be accepting SRs into it.
I have 13 python- packages not in d:l:p. Should I SR a copy to singlespec? I also have a bunch of non-python packages that have python- sub-packages for python bindings. Should I just ensure manually that they build python2- and python3- sub-packages? I'm the only consumer of these python binding sub-packages. Should I just drop python- versions of the sub-packages? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

hello, On 22.2.2017 06:08, Greg Freemyer wrote:
I have 13 python- packages not in d:l:p. Should I SR a copy to singlespec?
No. I'll be submitting all of singlespec to d:l:py at some point, this would only cause confusion. Let me know if you want me to look at the packages though.
I also have a bunch of non-python packages that have python- sub-packages for python bindings. Should I just ensure manually that they build python2- and python3- sub-packages?
At the moment, old-style packages should work fine, so I suggest leaving it as-is, until there is singlespec support for packages like this. (it's the next thing on my todo-list once the transition is on its way) You can rename python- bindings to python2-, but this will probably only be acceptable for Factory.
I'm the only consumer of these python binding sub-packages. Should I just drop python- versions of the sub-packages?
I'm not sure I understand the question. Are you asking if you should only build Python 3 version? Probably not -- you might be the only consumer now, but why not have both (or all) pythons supported. Or are you asking about moving from python- to python2- ? Again, that is up to you.
Thanks Greg
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Feb 22, 2017 at 8:17 AM, jan matejek <jmatejek@suse.com> wrote:
Or are you asking about moving from python- to python2- ? Again, that is up to you
Thanks, then I will leave them as they are. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

jan matejek-4 wrote
hello,
On 22.2.2017 06:08, Greg Freemyer wrote:
I have 13 python- packages not in d:l:p. Should I SR a copy to singlespec?
No. I'll be submitting all of singlespec to d:l:py at some point, this would only cause confusion.
Let me know if you want me to look at the packages though.
Oh, i just submitted a few to d:l:p:singlespec, should I have sent them to plain d:l:p instead? And also, since I've started playing with singlespec only today, could you please tell me what I'm doing wrong here? %ifpython2 BuildRequires: %{python_module argparse} %endif OBS is still complaining about a missing python3-argparse. Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Luigi Baldoni wrote
And also, since I've started playing with singlespec only today, could you please tell me what I'm doing wrong here?
%ifpython2 BuildRequires: %{python_module argparse} %endif
OBS is still complaining about a missing python3-argparse.
I read the introduction messages more attentively and found the answer there. Sorry, sometimes I jump the gun. Anyway I have another question: is %ifpython2 only usable for Requires and the like? I couldn't make it work for a generic command in %prep. Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 1.3.2017 21:35, Luigi Baldoni wrote:
Luigi Baldoni wrote
And also, since I've started playing with singlespec only today, could you please tell me what I'm doing wrong here?
%ifpython2 BuildRequires: %{python_module argparse} %endif
for completeness: instead of using %ifpython here, simply write: BuildRequires: python-argparse without conditionals and without %python_module macro
I read the introduction messages more attentively and found the answer there. Sorry, sometimes I jump the gun.
:)
Anyway I have another question: is %ifpython2 only usable for Requires and the like? I couldn't make it work for a generic command in %prep.
%ifpython2 and friends don't work in %prep/%build/%install/%check, because these sections are common to all the subpackages. IOW, the code in %prep and friends is only run once per build, and must handle all pythons at once. You can test for %if 0%{?have_python2}. But this will be true when *python2 is one of the pythons for which we build*. It does not mean that the section will only run for building the python2 version. What are you trying to do? Can't you simply do it without the conditional? m.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com.

jan matejek-4 wrote
On 1.3.2017 21:35, Luigi Baldoni wrote:
Luigi Baldoni wrote
And also, since I've started playing with singlespec only today, could you please tell me what I'm doing wrong here?
%ifpython2 BuildRequires: %{python_module argparse} %endif
for completeness: instead of using %ifpython here, simply write:
BuildRequires: python-argparse
without conditionals and without %python_module macro
And that did the trick.
Anyway I have another question: is %ifpython2 only usable for Requires and the like? I couldn't make it work for a generic command in %prep.
%ifpython2 and friends don't work in %prep/%build/%install/%check, because these sections are common to all the subpackages. IOW, the code in %prep and friends is only run once per build, and must handle all pythons at once.
In other words I need to put the logic into an external script or setup.py itself to differentiate between py2 and py3, right?
What are you trying to do? Can't you simply do it without the conditional?
In the case in question, argparse doesn't exist for python3, so setup.py fails setup_requires. I need a patch, I suppose. Also, what about libraries that exist only for py2 or py3? Does it make sense to use singlespec for those? (I failed when I tried) Will we have to submit plain python3-foo to d:l:p once d:l:p3 is eliminated? Regards P.S: Should I keep submitting stuff to d:l:p:singlespec? If the conversion script is around the corner I'll just wait. -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 2.3.2017 18:16, Luigi Baldoni wrote:
%ifpython2 and friends don't work in %prep/%build/%install/%check, because these sections are common to all the subpackages. IOW, the code in %prep and friends is only run once per build, and must handle all pythons at once.
In other words I need to put the logic into an external script or setup.py itself to differentiate between py2 and py3, right?
well, the "external script" will also only run once. you can use "%python_exec script.py" to run it once for every flavor or something like: %{python_expand sh script.sh --python=$python} You can't, for example, conditionally apply patches, because the source tree is shared. (which i suppose is what you want to do) So the logic of the patch would have to be included in setup.py. Or you could apply and unapply the patch before/after build, see below. if you're taking special steps for build, you could do: %{python_expand ./do-the-special-step %$python_build} similar for %python_install or even: %{python_expand if "$python" == "python2"; then ./do-special-python2-step %python2_build else %$python_build fi} (everything inside the {braces} for python_expand is part of the loop. But if it has multiple lines, the first one must not be empty. RPM limitation, i suppose.)
What are you trying to do? Can't you simply do it without the conditional?
In the case in question, argparse doesn't exist for python3, so setup.py fails setup_requires. I need a patch, I suppose.
Yes, you need a patch, and make it so that the requirement is completely removed :) argparse module is part of Python from 2.7 and 3.2, so unless you're building for SLE11, you don't need it.
Also, what about libraries that exist only for py2 or py3? Does it make sense to use singlespec for those? (I failed when I tried)
For python2, leave it as is. Only if it is a new package, call it "python2-something". If it is an existing package, add "Provides: python2-something". For python3, it's unclear. We will be supporting pypy3 as well, maybe the library will work there? It would be better to write it as singlespec and "%undefine have_python2" at start. This might fail because of bugs. The scenario should work but it is completely untested as of now.
Will we have to submit plain python3-foo to d:l:p once d:l:p3 is eliminated?
yes.
Regards
P.S: Should I keep submitting stuff to d:l:p:singlespec? If the conversion script is around the corner I'll just wait.
We will now be dropping packages from d:l:py:singlespec as they go to d:l:py, so at this point you can submit to d:l:py directly. I will run a mass conversion sometime next week, but we will probably need to review every autoconverted package. So if you are doing it manually already, you can continue. Or you can wait and save yourself a bit of work :) regards m.
-- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

jan matejek-4 wrote
On 2.3.2017 18:16, Luigi Baldoni wrote:
Also, what about libraries that exist only for py2 or py3? Does it make sense to use singlespec for those? (I failed when I tried)
For python3, it's unclear. We will be supporting pypy3 as well, maybe the library will work there? It would be better to write it as singlespec and "%undefine have_python2" at start. This might fail because of bugs. The scenario should work but it is completely untested as of now.
In fact it creates both py2 and py3 rpms, populates them both with py3 files and then complains about the conflict:/ I guess I'll submit it plain. Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi Jan, what should I do if I want to specify a minimum version for a BuildRequires? Something like: BuildRequires: python-six >= 1.9.0 It seems that %{python_module} does not handle this case. Cheers, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 2017-02-28 at 11:43 +0100, Thomas Bechtold wrote:
Hi Jan,
what should I do if I want to specify a minimum version for a BuildRequires? Something like:
BuildRequires: python-six >= 1.9.0
It seems that %{python_module} does not handle this case.
Seems to be already fixed in git and devel:languages:python . Just not yet in Factory. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 28.2.2017 12:00, Thomas Bechtold wrote:
On Tue, 2017-02-28 at 11:43 +0100, Thomas Bechtold wrote:
Hi Jan,
what should I do if I want to specify a minimum version for a BuildRequires? Something like:
BuildRequires: python-six >= 1.9.0
It seems that %{python_module} does not handle this case.
Seems to be already fixed in git and devel:languages:python . Just not yet in Factory.
the right way to spell requirements like this is %{python_module six >= 1.9.0} there was a bug in the Factory definition that I only discovered recently when a package broke :) the Factory definition is already updated in prjconf so the resolver should pull in the right dependencies; updated definition in python-rpm-macros should appear in Factory soon. and for the record, the standard compatibility shim should spell, instead of: %{?!python_module:%define python_module() python-%1 python3-%1} should be: %{?!python_module:%define python_module() python-%{**} python3-%{**}} i'm in the process of putting all of this in the wiki m.

Hi, On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.)
Why? What if I only want the py2 version (including only the py2 dependencies)? Having the "binary" only shipped in the py3 package means that I need all python3 packages installed. Best Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 28.2.2017 12:31, Thomas Bechtold wrote:
Hi,
On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.)
Why? What if I only want the py2 version (including only the py2 dependencies)? Having the "binary" only shipped in the py3 package means that I need all python3 packages installed.
Why would you want "only the py2 version?" if it's a tool for which python is an implementation detail, you *should not care* which version of python it is using. The point of this is gradually moving towards python3-as-default. This should mean that after enough packages are converted, the typical installation will only have a Python 3 stack, not a Python 2 one. In the meantime, you will need both, which is impractical, but it seems better than doing a big switch-flip and mass-changing every "python-*" to "python3-*". Also IIRC this (having both stacks) is already the case because of some stacks (KDE, also GNOME i think?) moving to python 3. OTOH, If it actually matters which python version you're using, then of course you keep both and optionally provide update-alternatives. That's what the addendum to this point says.
Best
Tom

On Tue, 2017-02-28 at 14:23 +0100, jan matejek wrote:
On 28.2.2017 12:31, Thomas Bechtold wrote:
Hi,
On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.)
Why? What if I only want the py2 version (including only the py2 dependencies)? Having the "binary" only shipped in the py3 package means that I need all python3 packages installed.
Why would you want "only the py2 version?"
There is a product called SUSE OpenStack Cloud and that uses only python2 . And we don't want to add (and maintain) all the python3 versions for a huge dependency list just because some binaries need the py3 version.
if it's a tool for which python is an implementation detail, you *should not care* which version of python it is using.
The point of this is gradually moving towards python3-as-default. This should mean that after enough packages are converted, the typical installation will only have a Python 3 stack, not a Python 2 one.
In the meantime, you will need both, which is impractical, but it seems better than doing a big switch-flip and mass-changing every "python- *" to "python3-*". Also IIRC this (having both stacks) is already the case because of some stacks (KDE, also GNOME i think?) moving to python 3.
OTOH, If it actually matters which python version you're using, then of course you keep both and optionally provide update-alternatives. That's what the addendum to this point says.
The question is what we want to recommend. I stumbled over this while I started to create a py2pack spec template for the single spec approach. Cheers, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Feb 28, 2017 at 8:36 AM, Thomas Bechtold <tbechtold@suse.com> wrote:
On Tue, 2017-02-28 at 14:23 +0100, jan matejek wrote:
On 28.2.2017 12:31, Thomas Bechtold wrote:
Hi,
On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.)
Why? What if I only want the py2 version (including only the py2 dependencies)? Having the "binary" only shipped in the py3 package means that I need all python3 packages installed.
Why would you want "only the py2 version?"
There is a product called SUSE OpenStack Cloud and that uses only python2 . And we don't want to add (and maintain) all the python3 versions for a huge dependency list just because some binaries need the py3 version.
As far as I knew, OpenStack upstream is mostly done on Python 3 porting. So why not just move everything over? -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, 2017-02-28 at 08:38 -0500, Neal Gompa wrote:
On Tue, Feb 28, 2017 at 8:36 AM, Thomas Bechtold <tbechtold@suse.com> wrote:
On Tue, 2017-02-28 at 14:23 +0100, jan matejek wrote:
On 28.2.2017 12:31, Thomas Bechtold wrote:
Hi,
On Fri, 2017-02-17 at 18:31 +0100, jan matejek wrote:
- If you are using update-alternatives, remove them. Instead mark the executable as %python3_only: %python3_only %{_bindir}/yourbinary In most cases, we only need one version of the executable. If the purpose of the tool is, e.g., reading EXIF metadata, we don't care if python 2 or 3 reads them. (And the library files are still installed for both.)
Why? What if I only want the py2 version (including only the py2 dependencies)? Having the "binary" only shipped in the py3 package means that I need all python3 packages installed.
Why would you want "only the py2 version?"
There is a product called SUSE OpenStack Cloud and that uses only python2 . And we don't want to add (and maintain) all the python3 versions for a huge dependency list just because some binaries need the py3 version.
As far as I knew, OpenStack upstream is mostly done on Python 3 porting. So why not just move everything over?
"Mostly done", that's why. I'm pretty sure that not all OpenStack projects we include have already python3 support. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 28.2.2017 14:36, Thomas Bechtold wrote:
There is a product called SUSE OpenStack Cloud and that uses only python2 . And we don't want to add (and maintain) all the python3 versions for a huge dependency list just because some binaries need the py3 version.
(...)
The question is what we want to recommend. I stumbled over this while I started to create a py2pack spec template for the single spec approach.
well, the "recommended approach" so far has been to do alternatives for every throwaway executable the package would install, and that seems wrong to me. It's made worse by the fact that the vast majority of packages install the executable with an unversioned name, so it's additional work to either a) patch the setup.py file or b) catch the executable after installation and rename it --- made worse with singlespec by the fact that %python_install is now a single step. So let's look at the possible ways to resolve this. First, it is still perfectly possible to use alternatives, there's a couple of rather helpful macros for that too. So if the list of "some binaries" is small enough, we could keep what I recommended, and do alternatives only for the packages in the list. Then there's the fact that in a typical setuptools-based case, the "binary" is the exact same script with a different shebang. I could write a macro, i dunno, %python_clone_executable, that takes the named executable and creates "executable-%{python_version}" for every flavor. (I would still very much prefer the default, simplest case to be "only put executable in one package". Even if the other option is simplified to a macro and a couple of filelist entries.) Then it's a question of whether we need *alternatives* or whether shipping versioned binaries is good enough for your case? And if the latter, I'd stay off alternatives where not required, and keep with %python3_only %{_bindir}/unversioned-executable m.

I am trying to build some new package directly in the singlespec way and I like the approach. To be able to find dependencies I added d:l:p and d:l:p:singlespec to my project for now but hit the problem of "have choice for…" How can I ensure that one choice is selected and the package can build? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, ONce again for taking this on....HELP..... On 02/17/2017 12:31 PM, jan matejek wrote:
Dear packagers,
<snip>
Conversion steps:
If you want to build for anything other than Factory, you need to include compatibility shims. This definition of the %python_module macro goes on top of your spec: %{?!python_module:%define python_module() python-%1 python3-%1} and a buildrequire: BuildRequires: python-rpm-macros
Wrap all your "BuildRequires: python-something": BuildRequires: %{python_module something} Do not do this in Requires or any other fields. If you have a buildrequire that should only apply to one python, say, python-enum34 only for python 2, do not wrap it.
At the end of the spec preamble, before %description, place the macro: %python_subpackages on a line by itself
Got this far only :( For an upcoming project I need python-datrie which currently only exists in d:l:p3 thus rather than create more things to be converted I figured I'd try myself on the single-spec use and get the package moved to d:l:p To start with I started copying things so I don't fiddle myself into a corner where rm -rf is my only recourse... So I copied (osc copypac) from d:l:p3 to home:rjschwei [1]. I set up the spec file to be single-spec to the point where I thought it should work. Locally I copied the setup into my checked out d:l:p project directory and then tried to build, but: -> osc build openSUSE_Factory unresolvable: nothing provides python2-pytest-runner However pytest-runner has already been moved to single-spec [2] thus I would expect python2-pytest-runner to be there. Confused..... Help is appreciated, Robert [1] https://build.opensuse.org/package/show/home:rjschwei/python-datrie [2] https://build.opensuse.org/package/view_file/devel:languages:python/python-p... -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo

Hi, On Fri, 2017-03-03 at 19:51 -0500, Robert Schweikert wrote: [...]
- At the end of the spec preamble, before %description, place the
macro: %python_subpackages on a line by itself
Got this far only :(
For an upcoming project I need python-datrie which currently only exists in d:l:p3 thus rather than create more things to be converted I figured I'd try myself on the single-spec use and get the package moved to d:l:p
To start with I started copying things so I don't fiddle myself into a corner where rm -rf is my only recourse... So I copied (osc copypac) from d:l:p3 to home:rjschwei [1]. I set up the spec file to be single-spec to the point where I thought it should work. Locally I copied the setup into my checked out d:l:p project directory and then tried to build, but:
-> osc build openSUSE_Factory unresolvable: nothing provides python2-pytest-runner
That works for me now. Maybe the package python2-pytest-runner was not yet build? Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 03/06/2017 01:57 AM, Thomas Bechtold wrote:
Hi,
On Fri, 2017-03-03 at 19:51 -0500, Robert Schweikert wrote: [...]
- At the end of the spec preamble, before %description, place the
macro: %python_subpackages on a line by itself
Got this far only :(
For an upcoming project I need python-datrie which currently only exists in d:l:p3 thus rather than create more things to be converted I figured I'd try myself on the single-spec use and get the package moved to d:l:p
To start with I started copying things so I don't fiddle myself into a corner where rm -rf is my only recourse... So I copied (osc copypac) from d:l:p3 to home:rjschwei [1]. I set up the spec file to be single-spec to the point where I thought it should work. Locally I copied the setup into my checked out d:l:p project directory and then tried to build, but:
-> osc build openSUSE_Factory unresolvable: nothing provides python2-pytest-runner
That works for me now. Maybe the package python2-pytest-runner was not yet build?
Well I did check and at least that status for the package in the web console showed that the build for pytest-runner had succeeded and the repo had published. Maybe now with the multi-version build the status in the UI is no longer consistent with the build? But I have no idea how to investigate this. @Jan, Did you look at this previously? I do not know who OBS determines the status. Could it be possible that OBS switches to "succeeded" an sets the repo status to "published" when only 1/2 of the build is complete, i.e. either the py3 or p2 build is done? Now I am stuck at: unresolvable: nothing provides python3-hypothesis nothing provides python3-pytest-runner but [1] shows the build of hypothesis for the target I used openSUSE_Leap_42.1 to be successful and the repo to be published. Also confirmed in the UI [2]. Or maybe I am hitting some buildinfo issue being triggered? Thanks, Robert [1] https://build.opensuse.org/package/show/devel:languages:python/python-hypoth... [2] https://build.opensuse.org/package/binaries/devel:languages:python/python-hy... -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

hello, On 7.3.2017 00:45, Robert Schweikert wrote:
-> osc build openSUSE_Factory unresolvable: nothing provides python2-pytest-runner
That works for me now. Maybe the package python2-pytest-runner was not yet build?
Well I did check and at least that status for the package in the web console showed that the build for pytest-runner had succeeded and the repo had published.
Maybe now with the multi-version build the status in the UI is no longer consistent with the build? But I have no idea how to investigate this.
@Jan,
Did you look at this previously? I do not know who OBS determines the status. Could it be possible that OBS switches to "succeeded" an sets the repo status to "published" when only 1/2 of the build is complete, i.e. either the py3 or p2 build is done?
Definitely not. there is still a single build step, only now it produces two (or more) RPMs. The monitor is correct, the only thing that could be happening is that the resolver is slow to propagate the changes (esp. in cases where the provided RPMs are now changed)
Now I am stuck at:
unresolvable: nothing provides python3-hypothesis nothing provides python3-pytest-runner
but [1] shows the build of hypothesis for the target I used openSUSE_Leap_42.1 to be successful and the repo to be published. Also confirmed in the UI [2]. Or maybe I am hitting some buildinfo issue being triggered?
note that you are NOT using d:l:py for the basis of your Leap build! In your home repo, you are building against vanilla Leap, which does not and will not have many of the packages. (and indeed, Factory seems to work fine) hope this helps m.
Thanks, Robert
[1] https://build.opensuse.org/package/show/devel:languages:python/python-hypoth... [2] https://build.opensuse.org/package/binaries/devel:languages:python/python-hy...

Hi, On 03/07/2017 07:48 AM, jan matejek wrote:
hello,
On 7.3.2017 00:45, Robert Schweikert wrote:
-> osc build openSUSE_Factory unresolvable: nothing provides python2-pytest-runner
That works for me now. Maybe the package python2-pytest-runner was not yet build?
Well I did check and at least that status for the package in the web console showed that the build for pytest-runner had succeeded and the repo had published.
Maybe now with the multi-version build the status in the UI is no longer consistent with the build? But I have no idea how to investigate this.
@Jan,
Did you look at this previously? I do not know who OBS determines the status. Could it be possible that OBS switches to "succeeded" an sets the repo status to "published" when only 1/2 of the build is complete, i.e. either the py3 or p2 build is done?
Definitely not. there is still a single build step, only now it produces two (or more) RPMs. The monitor is correct, the only thing that could be happening is that the resolver is slow to propagate the changes (esp. in cases where the provided RPMs are now changed)
Now I am stuck at:
unresolvable: nothing provides python3-hypothesis nothing provides python3-pytest-runner
but [1] shows the build of hypothesis for the target I used openSUSE_Leap_42.1 to be successful and the repo to be published. Also confirmed in the UI [2]. Or maybe I am hitting some buildinfo issue being triggered?
note that you are NOT using d:l:py for the basis of your Leap build! In your home repo, you are building against vanilla Leap, which does not and will not have many of the packages.
Yes, in home:rjschwei the project is not set up correctly. I copied the content to d:l:py locally, which has other packages checked out and ran the build there. The error is generated in this local directly which does build against d:l:py. And yes build against Factory worked. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo

hello, On 7.3.2017 22:36, Robert Schweikert wrote:
Yes, in home:rjschwei the project is not set up correctly. I copied the content to d:l:py locally, which has other packages checked out and ran the build there. The error is generated in this local directly which does build against d:l:py. And yes build against Factory worked.
I'm afraid i don't understand your configuration. Can you set up a subproject in OBS and reproduce your problem there? thanks m.
Later, Robert

On 03/08/2017 08:02 AM, jan matejek wrote:
hello,
On 7.3.2017 22:36, Robert Schweikert wrote:
Yes, in home:rjschwei the project is not set up correctly. I copied the content to d:l:py locally, which has other packages checked out and ran the build there. The error is generated in this local directly which does build against d:l:py. And yes build against Factory worked.
I'm afraid i don't understand your configuration.
Can you set up a subproject in OBS and reproduce your problem there?
OK, a bit better to follow now I hope [1] If I add %{python_sitelib}/* to the %files section I end up with: [ 14s] RPM build errors: [ 14s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-datrie-0.7.1-0.x86_64/usr/lib/python2.7/site-packages/* Thanks, Robert [1] https://build.opensuse.org/package/live_build_log/home:rjschwei/python-datri... -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo

hello, On 12.3.2017 15:41, Robert Schweikert wrote:
If I add %{python_sitelib}/*
to the %files section I end up with:
[ 14s] RPM build errors: [ 14s] File not found: /home/abuild/rpmbuild/BUILDROOT/python-datrie-0.7.1-0.x86_64/usr/lib/python2.7/site-packages/*
that's because of the difference between "sitelib" (for noarch packages) and "sitearch" (for arch-dependent ones). You'll note that this message says file not found in "/usr/lib", and the error message from your build log says that unpackaged files are in "/usr/lib64" in this case, the right entry in filelist is: %{python_sitearch}/* hope this helps m.
Thanks, Robert
[1] https://build.opensuse.org/package/live_build_log/home:rjschwei/python-datri...

hello, there is now a wiki page that supersedes the following instructions. It will be kept up to date, which is impossible with an e-mail :) see: https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec Notably a significant bug is fixed:
This definition of the %python_module macro goes on top of your spec: %{?!python_module:%define python_module() python-%1 python3-%1}
should be: %{?!python_module:%define python_module() python-%{**} python3-%{**}} regards m.

There's still something I don't understand: how do I handle runtime dependencies if they're different for py2 and py3? And if I put python-foo and python3-bar in Requires, how is Factory going to untangle that? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 7.3.2017 18:42, Luigi Baldoni wrote:
There's still something I don't understand: how do I handle runtime dependencies if they're different for py2 and py3?
you wrap them in %ifpython2 / %ifpython3 / %ifpypy3 declarations i have clarified this a little in point 3. Please let me know if you still think that this should be explained better, or maybe more prominently?
And if I put python-foo and python3-bar in Requires, how is Factory
going to
untangle that?
python-foo will be translated to python2-foo, python3-foo, or whichever is appropriate for the target package. If your package is called "python3-something", then python3-bar will get the same treatment. The rewriter is looking for packages that start the same as the main package. So basically, if your package is called "python3-something", then it expects to see: Name: python3-something Requires: python3-foo and creates subpackage with: Name: python2-something Requires: python2-foo If your package is *not* called python3, but only "python-something", so it looks like this: Name: python-something Requires: python3-foo then "python3-foo" is left alone -- and copied to all subpackages, so even "python2-something" will require "python3-foo". What you probably mean to write in such case is: Name: python-something %ifpython3 Requires: python3-foo %endif in which case, only the "python3-something" package gets the "python3-foo" requirement. You could also say: Name: python-something %ifpython3 Requires: python-foo %endif and the same thing would happen: your "python3-something" package gets "python3-foo" requirement. --- If you need to avoid this, and simply copy the unchanged package name, you need to hide it behind a macro: Name: python-something %define oldpython python Requires: %{oldpython}-foo in this case, all subpackages (python2-something, python3-something) have requirement on "python-foo". hope this helps m.

On 03/07/2017 10:39 AM, jan matejek wrote:
hello, there is now a wiki page that supersedes the following instructions. It will be kept up to date, which is impossible with an e-mail :)
see: https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec
Notably a significant bug is fixed:
OK, now that the train is rolling I think we need to come back to the other part of the discussion, i.e. what to keep in d:l:py and what to evict, as if I remember correctly that point was postponed. There exist packages (python3-kiwi) for example for which it really makes no sense to build a Py2 and a Py3 version. So the question is, I think, do we keep packages that only need to be built in one version of Python in d:l:py? If the answer is yes we'll need some way to configure things that way in the spec, i.e. %{only_build_py3} for example. If the answer is no, we need to evict those packages and document accordingly. Thoughts? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo

I also have another question: how come %python_expand does not expand %{$py_ver}? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, Mar 12, 2017 at 1:38 PM, Luigi Baldoni <aloisio@gmx.com> wrote:
I also have another question: how come %python_expand does not expand %{$py_ver}?
Regards
I think it only works with the full "python" word, not "py". That macro is deprecated anyway, the new "%{$python_version}" should work fine, although in most situations you want %{$python2_bin_suffix}, which gives unique names for different python flavors that have the same version (like potentially python3 and pypy3).. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 02/17/2017 12:31 PM, jan matejek wrote:
Dear packagers,
this is an overview of how singlespec works and how to use it for your package. First, some key concepts:
- It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py.
<snip> I just realized that we broke quilt with the new macros :( error: line 30: Dependency tokens must begin with alpha-numeric, '_' or '/': BuildRequires: %{python_module setuptools} The %prep section of python-azure-mgmt-authorization.spec failed; results may be incomplete I guess quilt needs to be taught new tricks? Of course the work around is to create diffs for needed patches the "old fashioned" way, but quilt is convenient and I think we should not take that away from packagers. Thoughts? Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo

On 03/18/2017 10:59 PM, Robert Schweikert wrote:
On 02/17/2017 12:31 PM, jan matejek wrote:
Dear packagers,
this is an overview of how singlespec works and how to use it for your package. First, some key concepts:
- It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py.
<snip>
I just realized that we broke quilt with the new macros :(
error: line 30: Dependency tokens must begin with alpha-numeric, '_' or '/': BuildRequires: %{python_module setuptools} The %prep section of python-azure-mgmt-authorization.spec failed; results may be incomplete
I guess quilt needs to be taught new tricks?
Of course the work around is to create diffs for needed patches the "old fashioned" way, but quilt is convenient and I think we should not take that away from packagers.
Thoughts?
Robert
I guess it won't be hard to teach quilt, but it will certainly need to be done, its used regularly by most serious packages, i'm guessing no one noticed this until now. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

19.03.2017 07:15, Simon Lees пишет:
On 03/18/2017 10:59 PM, Robert Schweikert wrote:
On 02/17/2017 12:31 PM, jan matejek wrote:
Dear packagers,
this is an overview of how singlespec works and how to use it for your package. First, some key concepts:
- It will allow you to build Python 2 and Python 3 (and PyPy 3 in the future) package from a single spec file, with very little manual effort. This means that if you're maintaining a separate python3-something in d:l:py3, you can now switch over to the common python-something in d:l:py.
<snip>
I just realized that we broke quilt with the new macros :(
error: line 30: Dependency tokens must begin with alpha-numeric, '_' or '/': BuildRequires: %{python_module setuptools} The %prep section of python-azure-mgmt-authorization.spec failed; results may be incomplete
I guess quilt needs to be taught new tricks?
Not really, you just need to have this macro defined. Either you install package providing this macro or do echo "%python_module setuptools this macro definition" >> ~/.rpmmacros
Of course the work around is to create diffs for needed patches the "old fashioned" way, but quilt is convenient and I think we should not take that away from packagers.
Thoughts?
Robert
I guess it won't be hard to teach quilt, but it will certainly need to be done, its used regularly by most serious packages, i'm guessing no one noticed this until now.
It is not quilt that fails, it is RPM. quilt simply does "rpmbuild -bp foo.spec"; it's RPM which handles macro expansion. I did hit it in the past and I did define macros for packages I required locally. I do not see how it can be fixed else.

Hello, Am Sonntag, 19. März 2017, 07:43:45 CET schrieb Andrei Borzenkov:
It is not quilt that fails, it is RPM. quilt simply does "rpmbuild -bp foo.spec"; it's RPM which handles macro expansion.
I did hit it in the past and I did define macros for packages I required locally. I do not see how it can be fixed else.
Wild guess: install the latest python-rpm-macros package? (and, in general, all *-macros packages you might need) Hmm, I wonder if we should have something like QuiltRequires: python-rpm-macros in our spec files ;-) Regards, Christian Boltz -- Will ich mich demnaechst mal ranmachen, allerdings momentan zuviel extrem unwichtige Sachen zu tun. [Marcel Schmedes in suse-linux] ^^ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

19.03.2017 18:55, Christian Boltz пишет:
Hello,
Am Sonntag, 19. März 2017, 07:43:45 CET schrieb Andrei Borzenkov:
It is not quilt that fails, it is RPM. quilt simply does "rpmbuild -bp foo.spec"; it's RPM which handles macro expansion.
I did hit it in the past and I did define macros for packages I required locally. I do not see how it can be fixed else.
Wild guess: install the latest python-rpm-macros package?
On Ubuntu? I had no issues on openSUSE :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

I'm still having problems with nosetests, that is I'm seeing encoding errors in 2.x when the original python 2 package didn't have any (while the python3 one did). Is there any difference, env-wise, in the singlespec 2.7 build part compared to the plain original package? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 21.3.2017 10:15, Luigi Baldoni wrote:
I'm still having problems with nosetests, that is I'm seeing encoding errors in 2.x when the original python 2 package didn't have any (while the python3 one did).
Is there any difference, env-wise, in the singlespec 2.7 build part compared to the plain original package?
are you sure you are running the right nosetests? they are somewhat problematic. the safest at the moment is either "%python_expand nosetests-%{$python_bin_suffix}" or "%python_exec -m nose" there are no env variables being set (as of now), if that is what you're asking m.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com.

jan matejek-4 wrote
On 21.3.2017 10:15, Luigi Baldoni wrote:
I'm still having problems with nosetests, that is I'm seeing encoding errors in 2.x when the original python 2 package didn't have any (while the python3 one did).
Is there any difference, env-wise, in the singlespec 2.7 build part compared to the plain original package?
are you sure you are running the right nosetests? they are somewhat problematic. the safest at the moment is either "%python_expand nosetests-%{$python_bin_suffix}" or "%python_exec -m nose"
there are no env variables being set (as of now), if that is what you're asking
I was running %python_expand %python_exec %{_bindir}/nosetests-%{$python_version}. Both this and %python_exec -m nose end with a "Unknown option s in python_expand()", while %python_expand nosetests-%{$python_bin_suffix} end with "Unknown option s in python_expand()", "Unknown option m in python_exec()" and "Unknown option m in python_expand()". All three of the above fail a test in the form of a "UnicodeDecodeError", which wasn't originally a problem in the plain python 2.x package. Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Luigi Baldoni wrote
I was running %python_expand %python_exec %{_bindir}/nosetests-%{$python_version}. Both this and %python_exec -m nose end with a "Unknown option s in python_expand()", while %python_expand nosetests-%{$python_bin_suffix} end with "Unknown option s in python_expand()", "Unknown option m in python_exec()" and "Unknown option m in python_expand()".
All three of the above fail a test in the form of a "UnicodeDecodeError", which wasn't originally a problem in the plain python 2.x package.
Addendum: according to the module developers, the right way to run the tests is executing either test/alltests.py or test3/alltests.py. I've tried various incarnations of %python_exec -c but I couldn't come up with a way to use the correct interpreter with the correct script. Am I missing something or do I really need a more complex script? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 03/21/2017 02:51 PM, Luigi Baldoni wrote:
Luigi Baldoni wrote
I was running %python_expand %python_exec %{_bindir}/nosetests-%{$python_version}. Both this and %python_exec -m nose end with a "Unknown option s in python_expand()", while %python_expand nosetests-%{$python_bin_suffix} end with "Unknown option s in python_expand()", "Unknown option m in python_exec()" and "Unknown option m in python_expand()".
All three of the above fail a test in the form of a "UnicodeDecodeError", which wasn't originally a problem in the plain python 2.x package.
Addendum: according to the module developers, the right way to run the tests is executing either test/alltests.py or test3/alltests.py. I've tried various incarnations of %python_exec -c but I couldn't come up with a way to use the correct interpreter with the correct script.
Am I missing something or do I really need a more complex script?
Is there a pointer to your project/package? Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Robert Schweikert-6 wrote
On 03/21/2017 02:51 PM, Luigi Baldoni wrote:
Luigi Baldoni wrote Addendum: according to the module developers, the right way to run the tests is executing either test/alltests.py or test3/alltests.py. I've tried various incarnations of %python_exec -c but I couldn't come up with a way to use the correct interpreter with the correct script.
Am I missing something or do I really need a more complex script?
Is there a pointer to your project/package?
home:alois:branches:devel:languages:python/python-docutils Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 21.3.2017 19:51, Luigi Baldoni wrote:
Luigi Baldoni wrote
I was running %python_expand %python_exec %{_bindir}/nosetests-%{$python_version}. Both this and %python_exec -m nose end with a "Unknown option s in python_expand()", while %python_expand nosetests-%{$python_bin_suffix} end with "Unknown option s in python_expand()", "Unknown option m in python_exec()" and "Unknown option m in python_expand()".
All three of the above fail a test in the form of a "UnicodeDecodeError", which wasn't originally a problem in the plain python 2.x package.
Addendum: according to the module developers, the right way to run the tests is executing either test/alltests.py or test3/alltests.py. I've tried various incarnations of %python_exec -c but I couldn't come up with a way to use the correct interpreter with the correct script.
Am I missing something or do I really need a more complex script?
Well, you have different steps for different interpreters. You'll need to do it the old way: python2 test/alltests.py python3 test3/alltests.py you could probably rename "test" to "test2" and then do something like %{python_expand NUMBER=`echo %{$python_version} | cut -c 1` $python test$NUMBER/alltests.py } But that seems pointless... if they have a separate test suite for python 2 and 3, i don't have high hopes for their suite running on pypy or something else anyway. regards m.
Regards
-- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

jan matejek-4 wrote
On 21.3.2017 19:51, Luigi Baldoni wrote:
Am I missing something or do I really need a more complex script?
Well, you have different steps for different interpreters. You'll need to do it the old way: python2 test/alltests.py python3 test3/alltests.py
you could probably rename "test" to "test2" and then do something like %{python_expand NUMBER=`echo %{$python_version} | cut -c 1` $python test$NUMBER/alltests.py } But that seems pointless... if they have a separate test suite for python 2 and 3, i don't have high hopes for their suite running on pypy or something else anyway.
I ended up using a horrid but functioning python one-liner. For some reason I couldn't make it work with bash. Still, I have another question: I was left with the impression that unified packages had to produce a module for both pythons but binaries only for python3. Is that correct or are there exceptions to that rule? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 23.3.2017 14:46, Luigi Baldoni wrote:
Still, I have another question: I was left with the impression that unified packages had to produce a module for both pythons but binaries only for python3. Is that correct or are there exceptions to that rule?
There are exceptions. If you expect that your package will be part of a Python 2 stack -- for example, if you're packaging something that is part of OpenStack (which is python2-based in openSUSE for now) -- then you should package binaries for all pythons, and use alternatives to choose between them. If there are differences between the python2 and python3 version -- for example, a webserver that is scriptable through python scripts -- then you should package versioned binaries ("/usr/bin/foo-2.7") for all pythons, and the unversioned one ("/usr/bin/foo") for Python 3 only. (if the package only installs /usr/bin/foo, you can use %python_clone to make /usr/bin/foo-2.7) For example, if your binary is called "runprogram": %python_install %python_clone %{buildroot}%{_bindir}/runprogram (...) %files %python_files %{_bindir}/runprogram-%{python_bin_suffix} %python3_only %{_bindir}/runprogram And of course when you actually *want* alternatives as a way to choose which version you run, then you should do that :) m.

jan matejek-4 wrote
On 23.3.2017 14:46, Luigi Baldoni wrote:
Still, I have another question: I was left with the impression that unified packages had to produce a module for both pythons but binaries only for python3. Is that correct or are there exceptions to that rule?
There are exceptions.
If you expect that your package will be part of a Python 2 stack -- for example, if you're packaging something that is part of OpenStack (which is python2-based in openSUSE for now) -- then you should package binaries for all pythons, and use alternatives to choose between them.
Ok. I have a number of binaries and for the sake of simplicity let's just call them foo and bar. So, %python_install installs them unversioned and then I have %python_clone -a %{buildroot}%{_bindir}/foo %python_clone -a %{buildroot}%{_bindir}/bar Since I don't want to create a group I also do this: %post %python_install_alternative foo %python_install_alternative bar %preun %python_uninstall_alternative foo %python_uninstall_alternative bar and then %files %{python_files} %python_alternative %{_bindir}/foo %python_alternative %{_bindir}/bar How come I see update-alternatives: using /usr/bin/foo-3.6 to provide /usr/bin/foo (foo) in auto mode update-alternatives: using /usr/bin/bar-3.6 to provide /usr/bin/bar (bar) in auto mode ... warning: file /usr/bin/foo: remove failed: No such file or directory warning: file /usr/bin/bar: remove failed: No such file or directory at the end of the build? (there are slight differences in Leap, not sure if relevant at this point) Am I forced to pick one of the executables and create a group around it or is there an alternative (no pun intended)? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/python-singlespec-how-to-convert-your-packa... Sent from the opensuse-packaging mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

hello, On 25.3.2017 11:27, Luigi Baldoni wrote:
Ok. I have a number of binaries and for the sake of simplicity let's just call them foo and bar.
So, %python_install installs them unversioned and then I have %python_clone -a %{buildroot}%{_bindir}/foo %python_clone -a %{buildroot}%{_bindir}/bar (...) %post %python_install_alternative foo %python_install_alternative bar (...) %files %{python_files} %python_alternative %{_bindir}/foo %python_alternative %{_bindir}/bar
this is the correct approach. Except, why don't you want to create a group? Does it make sense in your package to use different versions of the accompanying tools?
How come I see
Nothing to do with number of groups. This is how update-alternatives seem to work.
update-alternatives: using /usr/bin/foo-3.6 to provide /usr/bin/foo (foo) in
you get this when an alternative provider changes automatically -- such as when there are two and you remove the currently used one, or when you install a higher priority alternative. (...)
warning: file /usr/bin/foo: remove failed: No such file or directory
This is actually a RPM warning; update-alternatives deleted /usr/bin/foo and RPM was supposed to do that. If you moved to %postun, you would get a slightly different error from update-alternatives telling you that the files it's checking are not present anymore. Speaking of which, please move to %postun. With the latest update, %preun will no longer work for uninstalling alternatives. I'll have to re-check all packages. regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 03/19/2017 01:02 PM, Andrei Borzenkov wrote:
19.03.2017 18:55, Christian Boltz пишет:
Hello,
Am Sonntag, 19. März 2017, 07:43:45 CET schrieb Andrei Borzenkov:
It is not quilt that fails, it is RPM. quilt simply does "rpmbuild -bp foo.spec"; it's RPM which handles macro expansion.
I did hit it in the past and I did define macros for packages I required locally. I do not see how it can be fixed else.
Wild guess: install the latest python-rpm-macros package?
On Ubuntu? I had no issues on openSUSE :)
Beats me, works now. Pretty sure I had the python-rpm-macros packages as a BuildRequires when it failed. Oh well, thanks and sorry for the noice. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Team Lead Public Cloud rjschwei@suse.com IRC: robjo -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (14)
-
Andrei Borzenkov
-
Christian Boltz
-
Dominique Leuenberger / DimStar
-
Greg Freemyer
-
jan matejek
-
jan matejek
-
Luigi Baldoni
-
Neal Gompa
-
Olaf Hering
-
Oliver Kurz
-
Robert Schweikert
-
Simon Lees
-
Thomas Bechtold
-
Todd Rme