Re: on packaging TurboGears 0.8.9
Gustavo Noronha Silva wrote: I plan to add turbogears and json-py to the python-modules team; Bob, what say you? Have you made any work on this front? Should I go on and upload those packages to Debian? I haven't been a very good team player, we duplicated some work. I have most of those packages (some dated) are in my personal repository. deb-src ftp://ftp.real-time.com/linux/real-time sid custom main contrib non-free Push what you got, I'll post any major differences for discussion and sync my stuff to alioth. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New python maintenance team
Raphael Hertzog wrote: But I would really like turbogears maintained within python-modules since it's mainly good glue between several general-purpose Python modules. (But it's up to you in the end.) Let's merge the projects. There is only 3 of us and I think it would be best to be part of a large project. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New python maintenance team
Raphael Hertzog wrote: (Please request the removal of pkg-turbogears on alioth once you don't need it any more) Waiting on confirmation and then I'll submit the remove request. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .egg in Debian summary?
Bob Tanner tanner at real-time.com writes: I don't think Debian should use the egg structure. Read and re-read the complete thread regarding .eggs in Debian and I cannot tell if any progress has been made. As just a package maintainer I was looking for the options to move forward. 1. Do nothing, go with the status quo as documented in the Debian python policy, which is no .egg's and unpackage everything into a sub-directory of site-packages. 2. Investigate easydeb http://cheeseshop.python.org/pypi/easydeb/ 3. Using Phillip's .egg-info solution http://permalink.gmane.org/gmane.comp.python.distutils.devel/2567 Any others? Re-approaching this topic. I'm still trying to get TurboGears (TG) packages and it requires .egg support. Any progress on the technical direction Debian will take regarding .eggs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-kid
Pavel ?imerda wrote: Hi people I debian/testing there's a deb package called just 'kid'. It's a very nice templating system for python. Debian's package 'kid' is for python2.3... so I'd maybe prefer calling it python2.3-kid. And there's no python2.4 version of this package... Although it's easy to install it using python2.4 setup.py install... it doesn't install 2.4's scripts properly. Pavel Officially, wait for DD to push it http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338276 Unofficially deb ftp://ftp.real-time.com/linux/real-time-debpool sid custom main deb-src ftp://ftp.real-time.com/linux/real-time-debpool sid custom main -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-sqlobject v0.7 package?
Ramon Bastiaans wrote: I was wondering on the status of a version 0.7 package for python-sqlobject. It's current package is still at version 0.6, while version 0.7 has been released in October 2005. I'll confess that I'm partly to blame for the delay. v0.7 needs formencode and Fabio contacted me about my ITP for formencode. I've been dragging my feeting waiting for the whole .egg/.deb debate to be resolved. I've removed the .egg stuff from the latest release, I just need to get the directory names debian compliant. I hope to work on it 01/22 or 01/23. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python .egg support in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Starting a separate thread from the formencode as .egg in Debian ?? discussion since this issue is internal to Debian and I don't want DD's to beat-up upstream development anymore. :-) Good or bad python .egg's are here to stay. Following the formencode as .egg in Debian ?? thread I understand the following. IF Debian decides -not- to support .egg's a few python code bases (modules, applications, etc) will break. Looking into the future more python code bases will move to .egg so the number of broken code bases will only increase. I want to state what I think is the obvious, Debian must support .egg's. NOTE: The implementation of how .egg's are supported can be left to another thread. Is there an agreement amongst the interested debian-python developers/packagers that Debian must support .egg's? Answering the -IF- will let us move forward to the HOW. - -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDi1++fPGnCSzBsogRAjI+AJwIQbPm5GWBYSGve4Rfly6nH2FmzACgw1Aa KojmA4grMV/vAyNfDr8qR20= =9tD4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python .egg support in Debian
On Monday 28 November 2005 03:22 pm, Josselin Mouette wrote: You are completely misunderstanding the issue. There can be no such thing as Debian support for eggs. There can only be some Debian packages of eggified software. And there will be, as some developers will want to make them. Verbage, I'll change mine to be Debian packages of eggified software. The problem is that eggs are broken by design, and we're trying to convince upstream to fix their flaws, not only for our benefit but for that of all distributions. Water under the bridge and it doesn't really matter. Upstream's design =might= be fatally flawed and you can argue this point for months and upstream will never change (ie Mozilla anyone?). Let's move past it. Deal with the technical issues and create the policies, framework, and potential tools used to make Debian packages of eggified software. As they don't seem to listen to any of the arguments that were showed, we'll obviously have to use crude hacks to get these applications in Debian. The only remaining question may be which hack is the less ugly. Stop swinging the Josselin-clue-by-four at upstream and turn all the energy into debian-python :-) Is easy-deb the less ugly of the hacks? -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 pgp2wdsJjIou5.pgp Description: PGP signature
.egg in Debian summary?
Bob Tanner wrote: I don't think Debian should use the egg structure. It apparently relies on building a long sys.path (even though through only a single .pth file); I'm not sure of how .eggs are implemented, but I'm going to cross-post this info to the python-distutils mailing list. Read and re-read the complete thread regarding .eggs in Debian and I cannot tell if any progress has been made. Still in the discussion/fact-finding stage? As just a package maintainer I was looking for the options to move forward. Looking at the thread, I think these are the options (skipping the pro's and con's for now): 1. Do nothing, go with the status quo as documented in the Debian python policy, which is no .egg's and unpackage everything into a sub-directory of site-packages. 2. Investigate easydeb http://cheeseshop.python.org/pypi/easydeb/ 3. Using Phillip's .egg-info solution http://permalink.gmane.org/gmane.comp.python.distutils.devel/2567 Any others? -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: formencode as .egg in Debian ??
Matthias Urlichs wrote: If it break Debian policies, please point me to the appropriate section(s) and documents. I wasn't able to find any related to python module packaging. zless /usr/share/doc/python/python-policy.txt.gz I put a zip_safe = False into the setup.py, the prevents the egg from being created, but it makes the directory structure like so: `-- usr |-- lib | `-- python2.4 | `-- site-packages | `-- FormEncode-0.4-py2.4.egg | |-- EGG-INFO | `-- formencode | |-- javascript | `-- util Reading python-policy 1.4, I believe a 3rd party module should be just /usr/lib/pythonX.Y/site-packages/module-dir Correct? I can fix this problem using a .pth file, but is that the proper thing to do? I'm using cdbs and I cannot seem to find the logic on where modules get installed, is it controllable via cdbs? -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: formencode as .egg in Debian ??
On Monday 21 November 2005 05:16 pm, you wrote: Is Debian python policy dated or wrong? Debian moving a different direction then upstream python? surely our policy needs to adopt the new schema. I don't think it's dated or wrong. there are things which we do want to prevent: - package more than one version of a module in the distribution, apparently that's something that the egg format encourages. - an copy all needed modules into an egg approach. IMO this is wrong for a distribution. If you look at more complex packages, you'll already find that style very often. and all these packages have to be modified to use a system version. I know that setuptools offers a possibility to install in the old way (directly into site-packages), for a distribution like Debian that looks like the preferred way. I'm not sure if you are distutils-sig, but I posted snippets from our email conversation and Ian Bickering, one of the main developers of distutils/setuptool had this to say: I do think we need to resolve these issues with Linux distributions. I'd encourage ... [Matthias] ... to join this list, and we can discuss how this stuff should work. I've attached Ian's email as well. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 Bob Tanner wrote: This isn't a problem, it's just that the Debian policy isn't up-to-date. Python eggs install this way, and many packages (e.g. TurboGears) require the new structure. Then we have a problem in the Debian world. :-( Here is a snippet of an email I received from the Debian powers. I also believe this individual is one of the authors of the python-policy for Debian. I've X'd the name/email to protect the innocent. I do think we need to resolve these issues with Linux distributions. I'd encourage the X in question to join this list, and we can discuss how this stuff should work. Some of what Python Eggs do are redundant with a Debian package (though that redundancy can be used to positive effect) and some parts of Eggs offer features that don't fit into Debian packaging very well (like multiple installations of different versions of the same library, which requires versions in the package names themselves in Debian). Also, .pth file management is a bit of an issue, and is something that should be addressed by Debian policy, as it's somewhere where packages should cooperate. There are performance issues with every package having its own .pth file. = snip == On Monday 21 November 2005 09:09 am, XXX XX wrote: $ dpkg -L python2.4-formencode [...] /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg /usr/share/doc/python2.4-formencode/copyright /usr/share/doc/python2.4-formencode/changelog.Debian.gz ??? Please don't do that in a Debian package. First question, why? Because you can't us it with a simple use formencode. pydoc doesn't work with eggs either. I think there's a good argument that Python isn't quite ready for installing zip files, in that lots of tools don't work that well with them right now. This can be addressed in code through distutils settings -- you can force all files to be unzipped globally in distutils.cfg, and perhaps Debian could hook into that (if they don't want to create a distutils.cfg file, which is reasonable as that can be useful for user configuration). If it break Debian policies, please point me to the appropriate section(s) and documents. I wasn't able to find any related to python module packaging. zless /usr/share/doc/python/python-policy.txt.gz Lastly that is the default installation method when using cdbs. Which I think just delegates it to the setup.py (ie authors choice?) Probably. .egg packages might be a nice generic way to ship Python stuff to random OS installations, but I don't think they should be used in standard Python packages that are shipped in a Linux distribution like Debian. = snip == To comply, I added a zip_safe = False to the setup() of FormEncode, then moved /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg/formencode TO /usr/lib/python2.4/site-packages/formencode Are you saying the comply-hack- above will potentially break other python packages (like Turbogears)? You lose metadata that TurboGears really wants to have; this isn't just dependency information, but also plugin information (which I don't think is being used in 0.7, but will be for 0.8). Python packages can't be expected to read Debian package metadata. Also more generally, I think Debian needs to play more nicely with user-installed packages, and if you rely purely on Debian metadata for detecting installed packages, you lose useful information. As of a few months ago
Re: formencode as .egg in Debian ??
On Tuesday 22 November 2005 12:15 am, Martin v. Löwis wrote: I don't think Debian should use the egg structure. It apparently relies on building a long sys.path (even though through only a single .pth file); I'm not sure of how .eggs are implemented, but I'm going to cross-post this info to the python-distutils mailing list. See below for additional comments. this adds additional costs to all import statements on startup. It gets worse if these are zipfiles, because then each import statement will have to look into each zipfile (until the import is resolved). The is the opposite of what I was told by upstream development over on distutils, snippet from Phillip J. Eby [EMAIL PROTECTED]: snip Note also that in many cases, the package will be a single .egg file, (analagous to a Java .jar file) rather than a directory, and files are preferable to directories in most cases as they make Python import processing faster. snip ( Rest of the comments debian-python specific) -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288
