Re: .egg in Debian summary?

[Brian Sutherland]

On Fri, Mar 31, 2006 at 01:26:41AM -0300, Gustavo Noronha Silva wrote:
> It even uses python-support =D The code is on pkg-turbogears svn repo at
> alioth, and I'll upload it soonish, I hope.
> 
> Comments?

Being a Zope-ish hacker myself, I'm very glad to have helped the
competition;)

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
  And she's EVIL!!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Raphael Hertzog]

On Fri, 31 Mar 2006, Gustavo Noronha Silva wrote:
> Em Ter, 2006-03-28 às 12:49 +0200, Brian Sutherland escreveu:
> > I really have no idea how this ought to be done, but here's my way of
> > doing it;) If it fries your hard disk, don't blame me. Also if anyone
> > has any additions/corrections, let me know.
> 
> I like your way!

Indeed. I checked the setuptools documentation and it's the only
(reasonable) way of doing it.

I updated my kid patch accordingly and sent it to Ross Burton so that we
can have kid 0.9 with egg support RSN I hope.

> It even uses python-support =D The code is on pkg-turbogears svn repo at
> alioth, and I'll upload it soonish, I hope.

Great ! I look forward the turbogears package... 

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Gustavo Noronha Silva]

Em Ter, 2006-03-28 às 12:49 +0200, Brian Sutherland escreveu:
> I really have no idea how this ought to be done, but here's my way of
> doing it;) If it fries your hard disk, don't blame me. Also if anyone
> has any additions/corrections, let me know.

I like your way!

> For example upstream converted python-pullparser package to setuptools
> between 0.0.6 and 0.0.7. At the time we only had setuptools version
> 0.6a8-0.1, so I had to patch the setup.py to remove setuptools (which
> is similar to your kid patch):

Thanks to your idea, comments and by reading and playing with
python-pullparser source package from unstable I was able to build a
CherryPy 2.2.0rc1 package which should be usable by stuff like
TurboGears:

[EMAIL PROTECTED]:~/debian/pkg-turbogears/unstable/build-area$ python
Python 2.3.5 (#2, Mar  6 2006, 10:12:24)
[GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.require ('CherryPy')
[CherryPy 2.2.0rc1 (/var/lib/python-support/python2.3)]
>>>
[EMAIL PROTECTED]:~/debian/pkg-turbogears/unstable/build-area$ python2.4
Python 2.4.3c1 (#2, Mar 29 2006, 08:34:35)
[GCC 4.0.3 (Debian 4.0.3-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.require ('CherryPy')
[CherryPy 2.2.0rc1 (/var/lib/python-support/python2.4)]
>>>

It even uses python-support =D The code is on pkg-turbogears svn repo at
alioth, and I'll upload it soonish, I hope.

Comments?

Thanks!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: .egg in Debian summary?

[Brian Sutherland]

On Mon, Mar 27, 2006 at 10:24:39PM +0200, Raphael Hertzog wrote:
> On Mon, 27 Mar 2006, Brian Sutherland wrote:
> [...]
> > For what it's worth, I will be converting most of my packages that build
> > with setuptools to use option 3.
> > 
> > That is, of course, until there is some kind of consenus/decision.
> 
> If you have done that, can you post your patch to the list ? I have never
> packaged Python related stuff yet, but I recently made a patch to update
> the kid package (#359012) and tried to look quickly what would be needed
> to achieve that but each time I ended with a .egg in the .deb ...
> 
> So it would be great to have a example of how this ought to be done.

I really have no idea how this ought to be done, but here's my way of
doing it;) If it fries your hard disk, don't blame me. Also if anyone
has any additions/corrections, let me know.

For example upstream converted python-pullparser package to setuptools
between 0.0.6 and 0.0.7. At the time we only had setuptools version
0.6a8-0.1, so I had to patch the setup.py to remove setuptools (which
is similar to your kid patch):

--- orig/setup.py
+++ mod/setup.py
@@ -73,10 +73,10 @@
 #---
 # the rest is constant for most of my released packages:

+#import ez_setup
+#ez_setup.use_setuptools()
-import ez_setup
-ez_setup.use_setuptools()

+from distutils.core import setup
-import setuptools

 if PACKAGE:
 packages, py_modules = [NAME], None
@@ -85,7 +85,7 @@

 doclines = __doc__.split("\n")

+setup(
-setuptools.setup(
 name = NAME,
 version = VERSION,
 license = LICENSE,


Now that setuptools 0.6a9-1 I can remove that patch, and patch my rules
and control as follows:
  
 % baz diff
* looking for [EMAIL PROTECTED]/debian-python--python-pullparser--1.0--patch-6 
to compare with
* comparing to [EMAIL 
PROTECTED]/debian-python--python-pullparser--1.0--patch-6: .. done.

* modified files

--- orig/control
+++ mod/control
@@ -2,7 +2,7 @@
 Section: python
 Priority: extra
 Maintainer: Brian Sutherland <[EMAIL PROTECTED]>
-Build-Depends-Indep: debhelper (>= 4.0.0), python-dev, python2.3-dev, 
python2.4-dev
+Build-Depends-Indep: debhelper (>= 4.0.0), python-dev, python2.3-dev, 
python2.4-dev, python2.3-setuptools (>= 0.6a9-1), python2.4-setuptools (>= 
0.6a9-1)
 Standards-Version: 3.6.2.1

 Package: python-pullparser


--- orig/rules
+++ mod/rules
@@ -35,7 +35,7 @@
install -D --mode 644 ChangeLog 
python-$(PACKAGE)/usr/share/doc/python-$(PACKAGE)/changelog
set -e;\
for ver in $(PYVERSIONS); do\
-   $(PYTHON)$$ver setup.py install --no-compile 
--prefix=debian/python$$ver-$(PACKAGE)/usr;\
+   $(PYTHON)$$ver setup.py install --no-compile 
--single-version-externally-managed --root=debian/python$$ver-$(PACKAGE);\
done

 .PHONY: binary-common

The contents of the deb come out like this then:

 % dpkg-deb -c ../../python2.3-pullparser_0.0.7-1_all.deb
drwxr-xr-x root/root 0 2006-03-28 12:38:15 ./
drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/
drwxr-xr-x root/root 0 2006-03-28 12:38:09 ./usr/lib/
drwxr-xr-x root/root 0 2006-03-28 12:38:09 ./usr/lib/python2.3/
drwxr-xr-x root/root 0 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/
drwxr-xr-x root/root 0 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/
-rw-r--r-- root/root  1537 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/PKG-INFO
-rw-r--r-- root/root 0 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/zip-safe
-rw-r--r-- root/root   231 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/SOURCES.txt
-rw-r--r-- root/root11 2006-03-28 12:38:10 
./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/top_level.txt
-rw-r--r-- root/root 12610 2006-01-01 22:44:41 
./usr/lib/python2.3/site-packages/pullparser.py
drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/share/
drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/share/doc/
drwxr-xr-x root/root 0 2006-03-28 12:38:14 
./usr/share/doc/python2.3-pullparser/
-rw-r--r-- root/root   446 2005-11-09 17:38:47 
./usr/share/doc/python2.3-pullparser/copyright
-rw-r--r-- root/root   410 2006-01-01 22:47:42 
./usr/share/doc/python2.3-pullparser/changelog.Debian.gz

Have Fun.

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
  And she's EVIL!!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Hypothetical pkg-python alioth project (was:Re: .egg in Debian summary?)

[Paul Wise]

On Tue, 2006-03-28 at 01:16 +0200, Carlos Galisteo wrote:

>  IMHO that would be a great way to mantain python modules, and also a
> good "place" for more inexperienced people (like me) to be useful by
> doing delegated stuff and learning from the inside.
> 
>  Wait...It seems there already exists a "Python Modules Packaging
> Team" project [1] in Alioth:

Correct. We use #debian-python (oftc) and the python-modules-team list
on alioth.

>  Anyone knowing about this project status?

We have some packages in SVN[1] (and one package in debian). Only a few
people involved[2]. We have yet to do a proper website[3], announcement
and callout.

 1. http://svn.debian.org/wsvn/python-modules/
 2. 
http://svn.debian.org/wsvn/python-modules/metainfo/python-modules.team?op=file&rev=0&sc=0
 3. 
http://svn.debian.org/wsvn/python-modules/www/python-modules-policy.rst?op=file&rev=0&sc=0

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Hypothetical pkg-python alioth project (was:Re: .egg in Debian summary?)

[Carlos Galisteo]

On Mon, 27 Mar 2006 22:24:39 +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> BTW, wouldn't it be time to create a pkg-python alioth project much like
> the pkg-perl one to globally co-maintain all the python modules ?

 IMHO that would be a great way to mantain python modules, and also a good 
"place" for more inexperienced people (like me) to be useful by doing delegated 
stuff and learning from the inside.

 Wait...It seems there already exists a "Python Modules Packaging Team" project 
[1] in Alioth:
 
 Registered: 2005-06-29 15:17
 Activity Percentile: 0%

 Anyone knowing about this project status?



[1]http://alioth.debian.org/projects/python-modules/

--- 
Carlos Galisteo  
Jabber_Id::cgalisteo en jabber.org 
PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg 
Key_Fingerprint::F888 6FBA 9145 B5A2 C187  66D6 5B8C 027A 69AD BE65 
--- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Raphael Hertzog]

On Mon, 27 Mar 2006, Brian Sutherland wrote:
> > > > 
[...]
> > My opinion is that we probably shouldn't distribute eggs but we must make
> > it possible for our users to use them. So I think that the egg meta-info
> > ought to be distributed either within a package directly (when the content
> > of the egg matches the content of a single package) or as separate
> > meta-packages depending on the various packages.
> > 
> > From what I understood this is solution 3 above.
> 
> For what it's worth, I will be converting most of my packages that build
> with setuptools to use option 3.
> 
> That is, of course, until there is some kind of consenus/decision.

If you have done that, can you post your patch to the list ? I have never
packaged Python related stuff yet, but I recently made a patch to update
the kid package (#359012) and tried to look quickly what would be needed
to achieve that but each time I ended with a .egg in the .deb ...

So it would be great to have a example of how this ought to be done.

BTW, wouldn't it be time to create a pkg-python alioth project much like
the pkg-perl one to globally co-maintain all the python modules ?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Brian Sutherland]

On Sat, Mar 25, 2006 at 04:09:52PM +0100, Raphael Hertzog wrote:
> > > 3. Using Phillip's .egg-info solution
> > > 
> 
> Well, since there's no progress, it's up to you as package maintainer to
> take the decision. The day when we have a real policy here, it will still
> be time to change things.
> 
> My opinion is that we probably shouldn't distribute eggs but we must make
> it possible for our users to use them. So I think that the egg meta-info
> ought to be distributed either within a package directly (when the content
> of the egg matches the content of a single package) or as separate
> meta-packages depending on the various packages.
> 
> From what I understood this is solution 3 above.

For what it's worth, I will be converting most of my packages that build
with setuptools to use option 3.

That is, of course, until there is some kind of consenus/decision.

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
  And she's EVIL!!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Raphael Hertzog]

Hi,

On Thu, 09 Feb 2006, Bob Tanner wrote:
> > 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 
> > 
> > 3. Using Phillip's .egg-info solution
> > 
> > 
> > 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?

Well, since there's no progress, it's up to you as package maintainer to
take the decision. The day when we have a real policy here, it will still
be time to change things.

My opinion is that we probably shouldn't distribute eggs but we must make
it possible for our users to use them. So I think that the egg meta-info
ought to be distributed either within a package directly (when the content
of the egg matches the content of a single package) or as separate
meta-packages depending on the various packages.

>From what I understood this is solution 3 above.

If you need change to existing packages to implement it, just file patches
on the various packages and hopefully they all be integrated soon thanks
to the 2.4 migration that is planned RSN.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .egg in Debian summary?

[Bob Tanner]

Bob Tanner  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 
> 
> 3. Using Phillip's .egg-info solution
> 
> 
> 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: [Distutils] .egg in Debian summary?

[Phillip J. Eby]

At 12:17 AM 11/23/2005 -0600, Bob Tanner wrote:

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 

3. Using Phillip's .egg-info solution


Any others?


#1 is pointless if your goal is to get TurboGears packaged.  As others have 
pointed out, future versions of TurboGears will be depending even more 
heavily on egg metadata than the current version does, and many of 
TurboGears' dependencies (e.g. SQLObject) already make use of egg metadata 
themselves, even if some only need the metadata for the sake of the 
projects that use them.


#2 or something like it is the best long-term approach in my view, in that 
it supports a more automated packaging process, while avoiding 
inter-project name conflicts and properly supporting namespace 
packages.  Also, under a 'pyegg' namespace, it could also be reasonable to 
install some projects such that 'require()' is necessary to use them.  But 
there are a number of practical hurdles -- including policy decisions -- 
that keep this option from being a quick and easy choice.


Practically speaking, I think #3 is the best compromise/transitional 
option, especially for packaging things like ElementTree, which is not 
packaged using setuptools, but which other projects need egg metadata 
for.  This allows the existing Debian Python packages to be utilized by the 
egg system without duplication, since you need only add an empty .egg-info 
directory to the existing Debian packages.  (Since the only metadata needed 
is the project name and version, which can be supplied from the .egg-info 
path.)


I double-checked the implementation, and I'm going to have to actually 
change setuptools a bit to support this, because currently it doesn't parse 
the version from an .egg-info directory name.  This is easy to fix, though, 
and I can put it out in 0.6a9, along with a 
--single-version-externally-managed option for the easy_install and install 
commands, and perhaps a bdist_rpm command using the same approach.  These 
changes shouldn't take long, though.  Until then, however, you would have 
to create an .egg-info/PKG-INFO file to be compatible with 
currently-released versions of setuptools.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Distutils] .egg in Debian summary?

[Vincenzo Di Massa]

Alle 07:17, mercoledì 23 novembre 2005, Bob Tanner ha scritto:

> 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 
>
> 3. Using Phillip's .egg-info solution
> 
>
2 & 3 can be merged using easy-deb with the right template of debian/rules.

even 1 & 1 can be merged using easy-deb to create a package that the debian 
developer will manually patch to remove/change egg functionality.

I think setuptools could really help Debian developer as well as Fedora, 
Mandriva, Gentoo... by:
1) providing functionality to install files outside of egg dir/zip (for 
example one could install code to site-packages and data-files to /usr/share/ 
or somewhere else)
2) providing a "fakeroot" option to fool setup.py (for example I want 
setuptools to install the files in debian/tmp/usr/lib/pythonX.Y/site-packages 
and scripts in debian/tmp/usr/bin and everithing must work when it copied 
to /usr/{bin,lib}.
2) providing a paseable output with setup process data like: dependencies 
(meet and unmett), files installed, author, license, and so on

All this will let people just "convert" the output of setuptools into an rpm 
specfile, debian dir, gentoo ebuild and so on.
All that is needed is just a common metadata format that can be parsed by 
tools like easy-deb, easy-rmp easy-ebuild easy-(???).
This way setuptools provides the information to distribution maintainers in a 
well documented, api independent way. Distribution maintainers can use this 
info to reorganize, repackage, invent new package formats, but without 
involving setuptools and python developers.

About the pythonpath and pth files handlind:
if a project A really wants to use project B eggs it can easily require them 
without the need for a pth file.
If project C wants to use project B, but project C is not setuptools aware one 
could patch project C (just adding require() to it) instead of paching 
project B and project A removing egg support from them.

Onother possible solution would be to have:
python-A
python-pypi-A
python-B
python-pypi-B
python-C

Where 
python-B) depends on python-pypi-A and just provides the pth file (handled 
like easy-deb does)
python-pypi-B) contains the egg

So project C will depend on python-B, which will install the pth. But if 
project B is required just by project A which is setuptools aware the 
dependency will be on python-pypi-B: the pth file will not be installed.

Vincenzo


___
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.messenger.yahoo.com

.egg in Debian summary?

[Bob Tanner]

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 

3. Using Phillip's .egg-info solution


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]