python singlespec: how to convert your package

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Andrei Borzenkov
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Robert Schweikert-6
In reply to this post by Andrei Borzenkov


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
[hidden email]
IRC: robjo
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

jan matejek-4
In reply to this post by Luigi Baldoni
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-package-tp5080741p5083373.html
> Sent from the opensuse-packaging mailing list archive at Nabble.com.
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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


Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Robert Schweikert-6


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
[hidden email]
IRC: robjo
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

jan matejek-4
In reply to this post by Luigi Baldoni
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-package-tp5080741p5083438.html
> Sent from the opensuse-packaging mailing list archive at Nabble.com.
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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

Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

jan matejek-4
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.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

Luigi Baldoni
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
Reply | Threaded
Open this post in threaded view
|

Re: python singlespec: how to convert your package

jan matejek-4
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: [hidden email]
To contact the owner, e-mail: [hidden email]

123