System package
b88...@gmail.com
nslu2-linux.org optware, I feel I just cannot keep up with TurboGears.
Also, you don't see TurboGears as system package(s) for debian, ubuntu,
FC, gentoo, fink, or darwinports. Why?
My guess is: TurboGears uses setuptools exclusively. Most TG end users
are just satisfied with the separation provided by a
~/.pydistutils.cfg, and thus don't care much about system packages.
It does not help that for most components, only eggs are available for
download from TurboGears.org. So even though setuptools provide a way
to create a --single-version-externally-managed system package from
tarballs, there is no tarballs to start with.
IMHO, this will only hurt TG adoption in the long run, especially with
TG having so many component dependencies. Although setuptools handles
dependencies quite well, it's still not at the same sophisticated level
as apt-get. Not even on par with ruby gems - IIRC so far there is no
command to cleanly remove egg for example.
On nslu2 which uses ARM CPU, those packages with C extension are better
packaged as system packages so end users don't need to worry about
compilation.
Why I'm writing this message? There are little things TG distribution
can help system packagers:
1. Ideally, in addition to the eggs, TG can also provide tarballs for
all components;
2. Or at least place subversion tags so tarball is easily re-creatable,
and publish these tags;
3. For pure python component, maybe provide some easy way to convert
normal eggs to --single-version-externally-managed eggs. (this is more
a request to setuptools).
Thanks for listening,
-Brian Zhou
http://www.nslu2-linux.org/wiki/Profiles/BrianZhou
Jorge Godoy
> As the package maintainer of python and various python packages on
> nslu2-linux.org optware, I feel I just cannot keep up with TurboGears.
What do you mean by keeping up with it? There are releases from time to time,
as with any software out there.
> Also, you don't see TurboGears as system package(s) for debian, ubuntu,
> FC, gentoo, fink, or darwinports. Why?
Not enough demand? I also don't see packages for Rails, Django, etc. Zope
still lacks packages in some distributions.
> My guess is: TurboGears uses setuptools exclusively. Most TG end users
> are just satisfied with the separation provided by a
> ~/.pydistutils.cfg, and thus don't care much about system packages.
You can use the subversion repository or package Turbogears for your own use.
The license doesn't prevent you from packaging and distributing it as well...
> It does not help that for most components, only eggs are available for
> download from TurboGears.org. So even though setuptools provide a way
> to create a --single-version-externally-managed system package from
> tarballs, there is no tarballs to start with.
You know that an egg is a zip file, right? Instead of doing "tar zxvf
package.tar.gz" you do "unzip package.egg".
godoy@jupiter /usr/lib/python/site-packages % l
RuleDispatch-0.5a0-py2.4-linux-i686.egg
-rw-r--r-- 1 root root 234635 2005-11-22 17:05
RuleDispatch-0.5a0-py2.4-linux-i686.egg
godoy@jupiter /usr/lib/python/site-packages % file
RuleDispatch-0.5a0-py2.4-linux-i686.egg
RuleDispatch-0.5a0-py2.4-linux-i686.egg: Zip archive data, at least v2.0 to
extract
godoy@jupiter /usr/lib/python/site-packages %
But I suppose that you've already found it out and you don't want to use "zip"
files... I don't see any reason to avoid using that, but you might have your
reasons. Sharing them here would be interesting.
> IMHO, this will only hurt TG adoption in the long run, especially with
> TG having so many component dependencies. Although setuptools handles
> dependencies quite well, it's still not at the same sophisticated level
> as apt-get. Not even on par with ruby gems - IIRC so far there is no
> command to cleanly remove egg for example.
It depends on how you installed the egg. In development mode there's an
--uninstall option that removes installed files. Even for deployment I like
using the develop option because it creates a link to some are that I have
full control and full knowledge of. I don't have to think about package
management tools messing with my site-packages directory. I also like it
because of this uninstall feature that the docs says is only available in
this mode.
> On nslu2 which uses ARM CPU, those packages with C extension are better
> packaged as system packages so end users don't need to worry about
> compilation.
End users don't need to worry about compilation if you use eggs as well. You
install the packages on a system wide install. Python takes care of finding
them on PYTHONPATH and using them. I don't see any difference here.
> Why I'm writing this message? There are little things TG distribution
> can help system packagers:
>
> 1. Ideally, in addition to the eggs, TG can also provide tarballs for
> all components;
eggs are zip files, they can be unzipped and used as source packages normally.
> 2. Or at least place subversion tags so tarball is easily re-creatable,
> and publish these tags;
There are tags. http://trac.turbogears.org/turbogears/browser/tags
> 3. For pure python component, maybe provide some easy way to convert
> normal eggs to --single-version-externally-managed eggs. (this is more
> a request to setuptools).
What is a "--single-version-externally-managed" egg?
--
Jorge Godoy <jgo...@gmail.com>
Jorge Vargas
As the package maintainer of python and various python packages on
nslu2-linux.org optware, I feel I just cannot keep up with TurboGears.
Also, you don't see TurboGears as system package(s) for debian, ubuntu,
FC, gentoo, fink, or darwinports. Why?
actually there 2 gentoo packages, one based on eggs and another on the source files , the problem is that none of them are official.
My guess is: TurboGears uses setuptools exclusively. Most TG end users
are just satisfied with the separation provided by a
~/.pydistutils.cfg, and thus don't care much about system packages.
yes that's exactly how it is
It does not help that for most components, only eggs are available for
download from TurboGears.org.
I agree
So even though setuptools provide a way
to create a --single-version-externally-managed system package from
tarballs, there is no tarballs to start with.
this at least in gentoo is a big problem since they are "agains" setuptools because it doesnt lets
IMHO, this will only hurt TG adoption in the long run, especially with
TG having so many component dependencies.
yes but it help setuptools
Although setuptools handles
dependencies quite well, it's still not at the same sophisticated level
as apt-get.
*cough* emerge *cough*
Not even on par with ruby gems - IIRC so far there is no
command to cleanly remove egg for example.
yes your right.
On nslu2 which uses ARM CPU, those packages with C extension are better
packaged as system packages so end users don't need to worry about
compilation.
yes that's the biggest issue at gentoo too.
Why I'm writing this message? There are little things TG distribution
can help system packagers:
yes coordination, Kevin is a very nice guy I'm sure he will reply soon.
1. Ideally, in addition to the eggs, TG can also provide tarballs for
all components;
the main TurboGears-0.9a6.tar.gz has a thirdparty dir which has all the necesary component, but your right it should be more maintainable if those files are distributed separately.
2. Or at least place subversion tags so tarball is easily re-creatable,
and publish these tags;
tags are already there.
3. For pure python component, maybe provide some easy way to convert
normal eggs to --single-version-externally-managed eggs. (this is more
a request to setuptools).
Jorge Vargas
Em Domingo 14 Maio 2006 15:09, b88...@gmail.com escreveu:
> It does not help that for most components, only eggs are available for
> download from TurboGears.org. So even though setuptools provide a way
> to create a --single-version-externally-managed system package from
> tarballs, there is no tarballs to start with.
You know that an egg is a zip file, right? Instead of doing "tar zxvf
package.tar.gz " you do "unzip package.egg".
not exactly there are two types of eggs "pure python" and "mixed" the mixed ones have precompile C code which is not ideal for many distros, that's why there so many cElementTree packages for TG.
> IMHO, this will only hurt TG adoption in the long run, especially with
> TG having so many component dependencies. Although setuptools handles
> dependencies quite well, it's still not at the same sophisticated level
> as apt-get. Not even on par with ruby gems - IIRC so far there is no
> command to cleanly remove egg for example.
It depends on how you installed the egg. In development mode there's an
--uninstall option that removes installed files. Even for deployment I like
using the develop option because it creates a link to some are that I have
full control and full knowledge of. I don't have to think about package
management tools messing with my site-packages directory. I also like it
because of this uninstall feature that the docs says is only available in
this mode.
Same thing happens went you look at it the other way, why will that program (easy_install) will mess up with my system packages? I remenber someone on gentoo saying I dont trust pipy installing lots of stuff on my machine without me knowing what they are.
> 3. For pure python component, maybe provide some easy way to convert
> normal eggs to --single-version-externally-managed eggs. (this is more
> a request to setuptools).
What is a "--single-version-externally-managed" egg?
its a way to tell setuptools to ignore dependancies, it's the recommended way of using eggs with package managers, so it will only copy the files to where they are supposed asumming all the dependancies are manage by someone else (in this case the package manager)
--
Jorge Godoy <jgo...@gmail.com >
Brian Zhou
allows egg to be managed by system package tools. If you don't know
this feature, you basically don't need it. And it's targeted towards
system packagers.
I know eggs are zip files. But that zip file usually is different from
the source tar ball in that it does not have a setup.py. You don't
expect system packagers to manually copy files to the right places, do
you?
As for "not enough demand", it's probably a chicken-n-egg problem. If
it cannot be easily packaged, less people will be interested in it.
Django is trivial to package; and ruby gems is mature enough that rails
does not need packaging - the ability to remove package at deployment
environment is the key.
I don't understand your argument regarding eggs with C extensions.
Fortunately all eggs with C extensions have tarball or zip
downloadable, so it's not a real issue right now. However for odd
platforms like x86_64 or ARM, it's critical to provide source tarball
or zip files, without which the end user will have to worry about
compilation.
The http://trac.turbogears.org/turbogears/browser/tags URL you gave is
not sufficient. Who knows what is the correspondence of TurboBOB 1.0
tag and TG 0.9a6 tag for example? It's not even specified in TurboGears
setup.py. Why not also also provide a source tarball? What is so
difficult about it? It can be provided on a separate page to avoid
confusion. For people testing python2.5, they can also build their own
eggs from source tarball.
Instead of thinking "I don't see packages for Rails, Django", why not
think this way, "if TurboGears can easily be packaged, maybe it can
attract even more people"? There is just some little effort needed to
make this happen, setuptools has been already made it possible by
providing the --single-version-externally-managed option.
-Brian Zhou
Gustavo Noronha Silva
> Also, you don't see TurboGears as system package(s) for
> debian, ubuntu,
> FC, gentoo, fink, or darwinports. Why?
>
> actually there 2 gentoo packages, one based on eggs and another on the
> source files , the problem is that none of them are official.
I'm packaging TurboGears for Debian. I uploaded my first working drafts
here:
TG 0.8.9:
http://people.debian.org/~kov/turbogears/
TG 0.9a6:
http://people.debian.org/~kov/tg0.9/
Testing and comments are welcome!
> the main TurboGears-0.9a6.tar.gz has a thirdparty dir which has all
> the necesary component, but your right it should be more maintainable
> if those files are distributed separately.
Please, please do it. I'm creating a tarball for my turbogears package
right now, and separate ones for turbokid and turbojson. If this
separation would be done upstream, it would be much saner to maintain
the packages.
See you,
--
Gustavo Noronha Silva <gustavo...@terra.com.br>
Kevin Dangoor
TurboGears. setuptools and egg-info are still necessary (so it's a
good thing we have that
--single-whatever-externally-managed-really-long-parameter), because
of plugins, but I can definitely tweak things to make things more
pleasant.
On 5/14/06, Gustavo Noronha Silva <gustavo...@terra.com.br> wrote:
> > the main TurboGears-0.9a6.tar.gz has a thirdparty dir which has all
> > the necesary component, but your right it should be more maintainable
> > if those files are distributed separately.
>
> Please, please do it. I'm creating a tarball for my turbogears package
> right now, and separate ones for turbokid and turbojson. If this
> separation would be done upstream, it would be much saner to maintain
> the packages.
OK, so it sounds like here's what's desired:
1) remove thirdparty packages from the TG tarball (I'd like to do this
anyhow... I'm considering eliminating the svn:externals and adding a
little script to let people easily grab the desired version).
2) Make all of the third party tarballs available on the TG download page
3) split out turbocheetah, turbojson and turbokid into their own svn
trees (with tags/branches/trunk)
I should write some better scripts to help me build a release, but
otherwise this is quite doable and reasonable.
Will that do it for you folks doing packaging?
Kevin
Jorge Godoy
>
> OK, so it sounds like here's what's desired:
>
> 1) remove thirdparty packages from the TG tarball (I'd like to do this
> anyhow... I'm considering eliminating the svn:externals and adding a
> little script to let people easily grab the desired version).
+15 on that (1 isn't just enough... ;-)) I've already asked for that a long
time ago, when I had more trees checked out. It will also help keeping more
than one branch checked out for developers of TG... :-) (Specially now, that
all externals are in sync on 1.0 and trunk... if they differ, the script can
be updated on the specific branch where a new version is needed.)
> 2) Make all of the third party tarballs available on the TG download page
Keeping both eggs and tarballs seems the best choice to me since it would make
both operations easier. Maybe a new page named "source" with tarballs is the
best options to avoid confusing newbies (I liked that suggestion from someone
on this thread...).
> 3) split out turbocheetah, turbojson and turbokid into their own svn
> trees (with tags/branches/trunk)
All plugins, inclusing tgfastdata as well. :-)
Making them require specific (or generic "> something") TG versions would help
solving dependencies problems as well.
> I should write some better scripts to help me build a release, but
> otherwise this is quite doable and reasonable.
>
> Will that do it for you folks doing packaging?
If I were still creating packages, I believe that this would do it. But since
I stopped doing that a few years ago, people might need a bit more than just
that...
Maybe providing tarballs for released versions of each component instead of
just tagging them would help more. Specially for automated packaging. This
was already asked on this thread...
--
Jorge Godoy <jgo...@gmail.com>
Jonathan LaCour
> I'm definitely interested in helping people making system packages of
> TurboGears.
Kevin also wrote:
> OK, so it sounds like here's what's desired:
>
> 1) remove thirdparty packages from the TG tarball (I'd like to do this
> anyhow... I'm considering eliminating the svn:externals and adding a
> little script to let people easily grab the desired version).
>
> 2) Make all of the third party tarballs available on the TG
> download page
>
> 3) split out turbocheetah, turbojson and turbokid into their own svn
> trees (with tags/branches/trunk)
>
> I should write some better scripts to help me build a release, but
> otherwise this is quite doable and reasonable.
On a related note, I had tons of problems trying to get py2exe working
on a TurboGears application because of setuptools-related problems.
Would the work you describe above help this cause at all?
I know its currently possible to get things working with py2exe, but
I also know its a huge, undocumented, pain in the butt :) It would
be fantastic if building a standalone executable using py2exe or
py2app was a part of TurboGears, or at least a more supported thing.
Sorry to hijack the thread, but this seems like a related problem.
--
Jonathan LaCour
http://cleverdevil.org
Kevin Dangoor
> 1) remove thirdparty packages from the TG tarball (I'd like to do this
> anyhow... I'm considering eliminating the svn:externals and adding a
> little script to let people easily grab the desired version).
>
> 2) Make all of the third party tarballs available on the TG download page
>
> 3) split out turbocheetah, turbojson and turbokid into their own svn
> trees (with tags/branches/trunk)
I've opened a ticket for this:
http://trac.turbogears.org/turbogears/ticket/878
Kevin
Brian Zhou
One question, are all the plugins necessarily to be in their own eggs?
Are they going to be shared by other frameworks?
-Brian Zhou
Kevin Dangoor
The template plugins are already usable outside of TurboGears.
FastData is not usable outside of TurboGears, but it will likely have
its own release schedule.
Kevin
Gustavo Noronha Silva
> 1) remove thirdparty packages from the TG tarball (I'd like to do this
> anyhow... I'm considering eliminating the svn:externals and adding a
> little script to let people easily grab the desired version).
Yeah!
> 2) Make all of the third party tarballs available on the TG download page
That would be nice, though pointing wherever they can be downloaded is
good too. I took a great deal of time to find the author website for
json-py, while packaging TG 0.8.9.
> 3) split out turbocheetah, turbojson and turbokid into their own svn
> trees (with tags/branches/trunk)
Please, and providing tarballs for each release would be awesome, as
well.
> I should write some better scripts to help me build a release, but
> otherwise this is quite doable and reasonable.
>
> Will that do it for you folks doing packaging?
That will make me a happier maintainer, sure =)
Thanks a lot, you guys are doing a great job!