gmane.linux.redhat.fedora.python

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-25T07:43:45

----- Original Message -----

I agree that monkey patching is not necessary, but it certainly makes things easier. I considered creating the wrapper class, but monkey patching just seemed as a better option ATM. Having said that, I'm open to any suggestions and I will rethink this as the library grows much larger than I previously thought it would.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Nick Coghlan — 2012-05-25T07:33:39

Is monkeypatching really necessary here? Monkeypatching affects global
process state (i.e. class definitions in imported modules), so it's a
fairly extreme approach to the problem of inconsistent method names that
prevent duck-typing. It's generally preferable to use a wrapper class or
a custom subclass to adapt between the two APIs at the point of use
rather than changing state that can be seen by every other module that
gets imported into the same process.

Cheers,
Nick.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Konstantin Zemlyak — 2012-05-23T08:58:01


Your own setup.py contains explicit import from pyp2rpmlib, thus 
monkeypatching happens even before setuptools/distribute gets imported.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-23T08:55:52

----- Original Message -----

Thanks a lot... I didn't know that all the modules get imported during install... I guess moving that code somewhere to the archive class will do fine.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Konstantin Zemlyak — 2012-05-23T08:51:56

Same for me on F15.


No, it's a problem with your monkeypatching of zipfile in 
pyp2rpmlib/archive.py(12):

# monkey patch ZipFile to behave like TarFile
ZipFile.getmembers = ZipFile.infolist
ZipFile.extractfile = ZipFile.open
ZipFile.open = ZipFile # this line is at fault here
ZipInfo.name = ZipInfo.filename

Real zipfile.ZipFile.open opens member of archive not an archive itself.
So in code above z.read(info.filename) ends up calling ZipFile instead 
of real zipfile.ZipFile.open, providing wrong aruments.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Nick Coghlan — 2012-05-23T08:06:00

Yep, 0.4.1 pip installs fine. I ran it over the parse module (which is a
test dependency I know I'm currently missing if I try to run my tests
from an RPM install) just to try it out.

I'll explore more tomorrow on what's involved in tweaking the templates.

Cheers,
Nick.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-23T08:00:41

----- Original Message -----

Yes, I can reproduce that. It seems to be a problem in the distribute package (a.k.a. python-setuptools in Fedora). I released version 0.4.1, that uses Python's internal distutils and should install fine. I will investigate this issue and let you know when I find out what's wrong.

Thanks :)

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Nick Coghlan — 2012-05-23T07:29:23

I'm stumped. I downloaded the tarball and unpacked it with Ark to see if
the unpack step was the source of the problem. I then ran setup.py
directly and got the output below.


$ sudo python setup.py install
running install
running bdist_egg
running egg_info
writing requirements to pyp2rpm.egg-info/requires.txt
writing pyp2rpm.egg-info/PKG-INFO
writing top-level names to pyp2rpm.egg-info/top_level.txt
writing dependency_links to pyp2rpm.egg-info/dependency_links.txt
reading manifest file 'pyp2rpm.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pyp2rpm.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/pyp2rpmlib
copying build/lib/pyp2rpmlib/utils.py ->
build/bdist.linux-x86_64/egg/pyp2rpmlib
copying build/lib/pyp2rpmlib/package_data.py ->
build/bdist.linux-x86_64/egg/pyp2rpmlib
copying build/lib/pyp2rpmlib/version.py ->
build/bdist.l

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-23T06:57:17

----- Original Message -----

Hmm, that is really strange, this works for me on F17. Could it be that it depends on Python version or tar version it was created with? I created the package on F17.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Nick Coghlan — 2012-05-23T06:48:34

Thanks, that makes sense - I hadn't really looked closely at pypi2rpm
until today (it had only been on my "learn more about this" list) so I
hadn't noticed the limitation. I'd previously tried using py2pack to
create SPEC files, and they required a lot of subsequent tweaking to
bring them up to something I considered acceptable (and that wasn't even
trying to get them up to full Fedora packaging standards).

Perhaps having "spec" or "srpm" in the name would make the difference
more obvious?

Regarding pyp2rpm itself, running "pip install pyp2rpm" (or
"easy_install pyp2rpm") on my Fedora 16 workstation gives me a traceback
with "RuntimeError: That compression method is not supported".

Regards,
Nick.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-23T06:30:39

----- Original Message -----

Yes, it is exactly as Matthias says.

pyp2rpm is a tool for packager, it creates an rpm specfile, which is prefilled with the automatically extractable data.
pypi2rpm is a tool for user who wants to create binary rpms, but it can't produce specfile nor srpm in any form.

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Matthias Runge — 2012-05-23T06:26:59

Pyp2rpm supports a packager to create an initial spec.
Using pypi2rpm there's IMHO no way to get produced rpms into fedora.
(because of missing srpm)

If you don't care about that, I guess, pypi2rpm will be good enough.

Matthias

Re: Introducing pyp2rpm - A python package to rpm specfile convertor

Nick Coghlan — 2012-05-23T06:16:29

How does this compare to Tarek Ziade's existing pypi2rpm project?

From a quick look, the main difference appears to be that pyp2rpm
creates a spec file only, while pypi2rpm creates the RPM directly.

Cheers,
Nick.

Introducing pyp2rpm - A python package to rpm specfile convertor

Bohuslav Kabrda — 2012-05-23T06:06:47

Hi all,
for past few days, I've been working on a project called pyp2rpm. It's a tool that allows you to easily convert python package from PyPI to an RPM specfile. I would like to get it tested before I package it into Fedora, so if anyone is interested, here are the links:

http://pypi.python.org/pypi/pyp2rpm
https://bitbucket.org/bkabrda/pyp2rpm

You can install pyp2rpm by running "easy_install pyp2rpm" or "pip-python install pyp2rpm".

I will be glad for any comments/suggestions for improvement (including comments like "hey, I don't understand your readme nor help and I don't know how to use that!", which is why i intentionally didn't put any information about usage here :) ).

Thanks!

Re: libpython2.7.so, /usr/lib or /usr/lib64, Liquid error parsingmarkdown

Toshio Kuratomi — 2012-05-01T15:16:39

Yeah -- on 64bit multilib, the system should find the 64 bit libraries in
/usr/lib64/ and on 32bit multilib systems, in /usr/lib/.  It's a little
strange to me that your program works with either the 64bit compiled library
or the 32bit compiled library.  (It used the 64bit lib when you symlinked
and the 32bit lib when you installed the 32bit package).  Normally the
program you've installed is linked at buildtime to one or the other (and
built to work with a library that expects certain types to be of a certain
size associated with that architecture).  This also seems to imply that the
library is not being loaded by the system dynamic linker but by something
else -- perhaps it's being brought in as part of a dlopen'd object.

My best guess is that this is a problem with one of the things that's making
use of libpython.  Perhaps the program was built on a 32bit system and it
therefore assumes that libraries are in /usr/lib/.  Perhaps the path is
hardcoded to be /usr/lib/ in the build scripts.

-Toshio
________

Re: libpython2.7.so, /usr/lib or /usr/lib64, Liquid error parsingmarkdown

Nick Fenwick — 2012-05-01T05:25:30

It seems that because I had only the 64 bit python rpms installed, I 
didn't have the 32 bit libraries.


This was a hack.  Installing i686 architecture fixed my problem more 
gracefully.

yum install libpython.i686

Do you feel this is a dependency problem in one of the other systems 
I've installed (ruby, octopress), and their dependency on python?  
Perhaps I should move this query onto some other forum, such as rvm (the 
ruby installer, some part of which installed rubypython).  There's a 
thread at https://github.com/imathis/octopress/issues/251 where the 
Octopress guy seems to be distancing himself from dependency management, 
which doesn't look promising if the ball's actually in his court.

Nick
_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

libpython2.7.so, /usr/lib or /usr/lib64, Liquid error parsing markdown

Nick Fenwick — 2012-05-01T04:47:53

Hi all,

I'm a first time poster looking for guidance about what seems to be a 
configuration or packaging problem on my system. I'm running Octopress, 
a blogging framework in Ruby, which uses Liquid running via Python to 
parse some embedded code blocks into a pretty format.

Environment:
Fedora Core 16 - 3.3.2-6.fc16.x86_64
python-2.7.2-5.2.fc16.x86_64
ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux]
rvm 1.13.0 (stable) by Wayne E. Seguin

Liquid failed out of the box with a codeblock that tried to use .html or 
.js suffixes, with a rather unhelpful error message in the blog post 
being formatted:

Liquid error: undefined method `Py_IsInitialized’ for 
RubyPython::Python:Module

Googling for this error led me to many other Octopress blogs (and 
others) with this error. They've deployed broken blog posts unwittingly 
(I hope).

I found that I have /usr/lib64/libpython2.7.so but nothing in /usr/lib. 
Some google results led me to try:

ln -s /usr/lib64/libpython2.7.so /usr/lib/libpython2.7.so

Th

Re: Django packages - proposed name changes

Bohuslav Kabrda — 2012-03-07T13:09:01

----- Original Message -----

Right, that was my original idea, I agree only on master :)

Re: Django packages - proposed name changes

Matthias Runge — 2012-03-07T12:59:49

Wah, no, I mean just F18 (our current master).

I thought we won't include the rename in F17, right?

Matthias

Re: Django packages - proposed name changes

Bohuslav Kabrda — 2012-03-07T12:51:17

----- Original Message -----

I'm not sure I understand you. If I am not mistaken, then F18 is master - did you mean F17 and master?

And please, some of the other guys, would you please cooperate with us?

Thank you all!

Re: Django packages - proposed name changes

Matthias Runge — 2012-03-07T12:40:03

Ok, after thinking about this, I'd request only f18 and master. There is no
real change besides the name.

Matthias