python-devel July 2010

python-devel@lists.fedoraproject.org

4 participants
5 discussions

private-shared-object-provides
by Thomas Spura 29 Jul '10

29 Jul '10

Hi list, with a recent rpmlint, there will be a new warning 'private-shared-object-provides'. This will always trigger a *.so file inside of %{python_sitearch} as a wrong dependency: """ A shared object soname provides is provided by a file in a path from which other packages should not directly load shared objects from. Such shared objects should thus not be depended on and they should not result in provides in the containing package. Get rid of the provides if appropriate, for example by filtering it out during build. Note that in some cases this may require disabling rpmbuild's internal dependency generator. """ Is there a easy way to fix the find-requires script, so this won't be emitted in next builds? The current workaround is to manually grep away the unwanted provides, but... it's a workaround. While viewing the current find-requires script I found the file '/usr/lib/rpm/python.prov', which apparently doesn't exist yet. Is this on someone's TODO list? If not, maybe I'll have a look. Thomas

1 1

PyPyStack feature
by David Malcolm 13 Jul '10

13 Jul '10

I'm extremely busy with 3 features for Fedora 14, and with other Python-related activities, and I can't realistically devote much time to the PyPy feature here: https://fedoraproject.org/wiki/Features/PyPyStack Unfortunately, the deadline for Feature submission for F14 was today, and that page isn't finished yet. I'm sorry for not asking for help earlier. If someone else wants to take this and run with it, that would be great. Otherwise, I hope to do it in Fedora 15. Dave

1 0

Dealing with namespaces
by Robin 'cheese' Lee 10 Jul '10

10 Jul '10

Hello! When packaging Zope packages, I face to multiple namespaces, for example, 'zope', 'zope.app', 'zc' and 'grokcore'. When installing a package like 'zope.component' through 'python setup.py install', the module it provides will go to %{python_sitelib}/zope/component . If no other zope.* packages installed, the %{python_sitelib}/zope/ directory will contain only the 'component/' directory. In this case, it will fail to import the 'zope.component' module trivially in Python, because the %{python_sitelib}/zope/ directory doesn't contain a file named '__init__.py'. So, we must provide %{python_sitelib}/zope/__init__.py through some rpm. And the rpm which provides %{python_sitelib}/zope/ and %{python_sitelib}/zope/__init__.py is called namespace holder rpm. I propose three candidate solutions: Candidate 1: per-project namespace holder rpm This is what I did for Zope2 and Grok in the Zope SIG repo[1]. So I provide two namespace holder rpms: python-zope-filesystem[2] and python-grok-filesystem[3]. python-zope-filesystem provides all the namespaces needed by Zope packages and python-grok-filesystem by Grok packages. That is, a namespace holder rpm may provides multiple namespaces needed by that project. Results of this candidate: Less namespace holder rpms, no .pth file needed, no mechanical method to decide a namespace contained by which rpm (see Candidate 2). Candidate 2(I really prefer): per-toplevel-namespace namespace holder rpm For each top-devel namespace, we provide a namespace holder rpm. For example, the zope and zope.app namespaces will be provided by an rpm(may named 'python-namespace-zope'), and zc and zc.recipe by another rpm(may named 'python-namespace-zc'). So we have a mechanical method to decide a namespace contained by which rpm. For example, given a new package named 'yes.ok.bye', when packaging it as rpm, it must require 'python-namespace-yes'. And if the yes.ok namespace is not provided by 'python-namespace-yes', we can just make a new version of 'python-namespace-yes'. And if 'python-namespace-yes' rpm is not available in Fedora, we can just make it, and it will definitely conflicts with no other rpms. Results of this candidate: More namespace holder rpms, no .pth file needed, can mechanically decide a namespace contained by which rpm. Candidate 3: No namespace holder rpm, long-name packages are installed as eggs. Most long-name packages(like zope.componet, not like paste) will be packaged as eggs, through http://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions . And for each of these packages, a .pth file is used to add new directory to sys.path. Results of this candidate: No namespace holder rpm needed, many .pth files needed and sys.path will turn huge if you install something like Grok. Unfortunately, I have to go to field work tomorrow and have no access to Internet for about a month. [1] http://fedorapeople.org/gitweb?p=cheeselee/public_git/zope-rpm.git;a=tree;h… [2]$ rpm -ql python-zope-filesystem /usr/lib/python2.6/site-packages/five /usr/lib/python2.6/site-packages/five/__init__.py /usr/lib/python2.6/site-packages/five/__init__.pyc /usr/lib/python2.6/site-packages/five/__init__.pyo /usr/lib/python2.6/site-packages/z3c /usr/lib/python2.6/site-packages/z3c/__init__.py /usr/lib/python2.6/site-packages/z3c/__init__.pyc /usr/lib/python2.6/site-packages/z3c/__init__.pyo /usr/lib/python2.6/site-packages/z3c/recipe /usr/lib/python2.6/site-packages/z3c/recipe/__init__.py /usr/lib/python2.6/site-packages/z3c/recipe/__init__.pyc /usr/lib/python2.6/site-packages/z3c/recipe/__init__.pyo /usr/lib/python2.6/site-packages/zc /usr/lib/python2.6/site-packages/zc/__init__.py /usr/lib/python2.6/site-packages/zc/__init__.pyc /usr/lib/python2.6/site-packages/zc/__init__.pyo /usr/lib/python2.6/site-packages/zc/recipe /usr/lib/python2.6/site-packages/zc/recipe/__init__.py /usr/lib/python2.6/site-packages/zc/recipe/__init__.pyc /usr/lib/python2.6/site-packages/zc/recipe/__init__.pyo /usr/lib/python2.6/site-packages/zope /usr/lib/python2.6/site-packages/zope/__init__.py /usr/lib/python2.6/site-packages/zope/__init__.pyc /usr/lib/python2.6/site-packages/zope/__init__.pyo /usr/lib/python2.6/site-packages/zope/app /usr/lib/python2.6/site-packages/zope/app/__init__.py /usr/lib/python2.6/site-packages/zope/app/__init__.pyc /usr/lib/python2.6/site-packages/zope/app/__init__.pyo [3] $ rpm -ql python-grok-filesystem /usr/lib/python2.6/site-packages/grokcore /usr/lib/python2.6/site-packages/grokcore/__init__.py /usr/lib/python2.6/site-packages/grokcore/__init__.pyc /usr/lib/python2.6/site-packages/grokcore/__init__.pyo /usr/lib/python2.6/site-packages/grokui /usr/lib/python2.6/site-packages/grokui/__init__.py /usr/lib/python2.6/site-packages/grokui/__init__.pyc /usr/lib/python2.6/site-packages/grokui/__init__.pyo /usr/lib/python2.6/site-packages/megrok /usr/lib/python2.6/site-packages/megrok/__init__.py /usr/lib/python2.6/site-packages/megrok/__init__.pyc /usr/lib/python2.6/site-packages/megrok/__init__.pyo Robin 'cheese' Lee

1 0

[Zope-SIG] Grok is available in the Zope SIG repo.
by Robin 'cheese' Lee 10 Jul '10

10 Jul '10

Hi, all Grok[1][2] is a simple and interesting Web framework based on Zope Toolkit(Zope3) and now available in the Zope SIG repo (i686, x86_64, source). Steps to make a trivial test: $ wget http://cheeselee.fedorapeople.org/yum/zope-sig.repo [3] $ su -c "cp zope-sig.repo /etc/yum.repos.d/" $ su -c "yum install grokproject" $ grokproject Sample [4] ( Input username and password ) $ cd Sample $ bin/paster serve parts/etc/deploy.ini ( Wait a moment ) $ xdg-open http://localhost:8080/ The package 'grokproject' is a bit patched[5] by me. Upstream grokproject will always try to install grok and all its dependencies through zc.buildout when creating a new project, the patched version gets rid of buildout sequence and generates full projects through PasteScript directly. I shall write a Readme.FEDORA to manifest this change more detailedly when I come back from field work. All the spec files are accessible through the Zope SIG git[6]. [1] http://grok.zope.org/ [2] http://grok.zope.org/doc/current/tutorial.html [3] zope-sig.repo is an alias of zope-cheese.repo . You can skip the first two steps if this repo has been installed to yum.repos.d [4] or 'paster create -t grok Sample' [5] http://fedorapeople.org/gitweb?p=cheeselee/public_git/zope-rpm.git;a=blob;f… [6] http://fedorapeople.org/gitweb?p=cheeselee/public_git/zope-rpm.git;a=tree;h… Cheers Robin 'cheese' Lee

1 0

About Zope SIG mailing list and progress report
by Robin 'cheese' Lee 05 Jul '10

05 Jul '10

Sorry for my late joining. A Zope specific mailing list may not be in urgent need by now. We can just use this mailing list, which is for Python packaging in general. The traffic of this mailing list is low and some of our decisions for Zope packagine may affect wider Python packaging practices. Gentoo has excellent support for Zope packages. http://packages.gentoo.org/package/net-zopeb/zope?arches=linux . And because Gentoo supports multiple versions of a package, the maintainability of Zope packages in Gentoo seems more rigorous. I am now working on Grok and should finish in days. We should not package Zope3, instead we may aim at BlueBream directly, which is in beta now. I am also waiting for Plone 4, which is in beta too. And I am still considering a Fedora enhancement for distribute(setuptools) and distutils. Robin

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel July 2010