Installation questions
oliver....@gmail.com
I just found TurboGears online, saw my favorite web app toys (CherryPy
& SQLObject) well integrated and was intrigued by the video. And as I
am currently looking for a web framework for a larger project, I am
evaluating the normal contenders so far. And now as I am ready to "turn
back" to plain CherryPy with stuff, your framework shows up. Nice
coincidence.
But what makes me a little uneasy so far is the installation page to be
honest. :) Let me state first, that I am more or less new to the Egg
stuff. The technology sounds cool, but I have zero experience with it
so far.
I have some stuff (Elementtree and cElementtree) installed already,
Fedora Core brings it along and uses it heavily. Hi,
I just found TurboGears online, saw my favorite web app toys (CherryPy
&
SQLObject) well integrated and was intrigued by the video. And as I am
currently looking for a web framework for a larger project, I am
evaluating
the normal contenders so far. And now as I am ready to "turn back" to
plain
CherryPy with stuff, your framework shows up. Nice coincidence.
But what makes me a little uneasy so far is the installation page to be
honest. :) Let me state first, that I am more or less new to the Egg
stuff.
The technology sounds cool, but I have zero experience with it so far.
Hopefully, my questions are to dumb.
I have some stuff (Elementtree and cElementtree) installed already,
Fedora
Core brings it along and uses it heavily. Does the Easy Install code
take care
of that? Or does it brutally install the egg version?
How about CherryPy, FormEncode and SQLObject? There I track the svn
repos and
have them installed already. Are they skipped too?
For the former packages it is obvious to me, why you use the beta
versions. :)
But what does kid 0.7 provide, that you use the alpha version instead
the
0.6.4 stable version?
Best regards,
Oliver
Phillip J. Eby
> I have some stuff (Elementtree and cElementtree) installed already,
> Fedora
> Core brings it along and uses it heavily. Does the Easy Install code
> take care
> of that? Or does it brutally install the egg version?
>
> How about CherryPy, FormEncode and SQLObject? There I track the svn
> repos and
> have them installed already. Are they skipped too?
What should happen is that EasyInstall will tell you that conflicting
packages are already installed, and abort the installation. You will
then have to give it a command line option to tell it whether to ignore
this or delete the conflicting packages, i.e. either
--delete-conflicting or --ignore-conflicts-at-my-risk. For more
information, see:
http://peak.telecommunity.com/DevCenter/EasyInstall
Note that EasyInstall will consider any non-Egg packages in
site-packages to be "conflicting", regardless of the version.
Old-style (pre-egg) Python packages do not carry any
universally-readable version information, so there is no way for
EasyInstall to detect what version is present. It simply looks at
whether there are packages or modules with the same names as ones in
the eggs you're installing. If such modules exist, and they will end
up before the egg on sys.path, blocking you from importing anything in
the egg, then it considers them "conflicting".
If you don't want to delete your existing packaged installations, the
best thing to do is follow the "Non-Root Installation" procedure
described on the EasyInstall doc page above. This will give you a
"virtual Python" with its own site-packages that inherits from your
systemwide one, and it will be safe to tell EasyInstall to
--delete-conflicting because it will just be deleting symlinks from
your "virtual Python" instead of from the real Python. It will have no
effect on your "real" system Python.
Oliver Andrich
first of all thanks for your detailed answer. I have now a python in a
box accompanied with TurboGears and friends. It works really fine. As
I will have to use this anyway for my personal website, it is okay for
me.
But as I appreciate your Easy Install system very much, I think a lot
of advocacy has to be done to get it up and running. Cause the problem
I encounter is by no means a unique problem, but at least on every
Linux system using Python for system tools (as far as I know Fedora,
Ubuntu and Gentoo) it can/will occur. Setting up a more or less
"personal" environment for each app can't be a solution, or having to
maintain a system installation of Python and an application
installation. Hopefully this is comprehensible, sadly my english has
to "polished" again.
Best regards,
Oliver
--
Oliver Andrich <oliver....@gmail.com> --- http://roughbook.de/
Kevin Dangoor
Your english has been fine for me!
I think an "additional installation information" document will be a
good thing. Python Eggs/Easy Install is a *huge* win for those of us
using Python, and it's well worth the minor adjustment in thinking
that it requires.
The quick installation instructions that exist now will work for some
people. I can forsee four cases already that deserve this extra
documentation:
1) conflicting packages, as in your case
2) non-root installation (for people who have no choice)
3) multi-version installation (you want to have TurboGears and its
dependencies, but you also want an older/newer version of a
dependency)
4) desire to try TurboGears with some dependency version other than
the "officially supported" ones
I'm not sure that I'll get to this document before Tuesday, but I'll try.
Kevin
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Oliver Andrich
first of all congratulations for your work. Nice framework. I spent
almost a whole day playing with it and I am more then happy so far.
> The quick installation instructions that exist now will work for some
> people. I can forsee four cases already that deserve this extra
> documentation:
>
> 1) conflicting packages, as in your case
> 2) non-root installation (for people who have no choice)
> 3) multi-version installation (you want to have TurboGears and its
> dependencies, but you also want an older/newer version of a
> dependency)
> 4) desire to try TurboGears with some dependency version other than
> the "officially supported" ones
>
> I'm not sure that I'll get to this document before Tuesday, but I'll try.
machinery". But you or the community should address these issues in
the near future.
Phillip J. Eby
> But as I appreciate your Easy Install system very much, I think a lot
> of advocacy has to be done to get it up and running. Cause the problem
> I encounter is by no means a unique problem, but at least on every
> Linux system using Python for system tools (as far as I know Fedora,
> Ubuntu and Gentoo) it can/will occur. Setting up a more or less
> "personal" environment for each app can't be a solution, or having to
> maintain a system installation of Python and an application
> installation.
Well, in most shared environments you need a way for users and/or
specific applications to have additional PYTHONPATH directories anyway,
so it's not really that much of an additional step. Apart from
setuptools itself, eggs can be installed in pretty much any directory
on your PYTHONPATH. However, in my quick answer to your earlier
question, I didn't want to get into the issue of whether TurboGears
would run with such a custom setup. In principle, it should be
possible for you to just select any directory on your regular PATH that
you have write privileges to, as long as you're willing to always use
require() to select packages when writing code that's not part of a
TurboGears project using "setup.py develop". That directory can then
become your custom environment, as long as you don't have any
conflicting packages earlier on sys.path.
It's likely to take a good while before any major Linux or BSD
distribution uses eggs as part of their standard installation and
packaging. Right now, it's not even a "blessed" Python standard, and
it would take a while for the distros to repackage their existing
Python packages to fit.
Ultimately, EasyInstall is intended to empower the individual Python
user and/or application to install the things they need, wherever they
need them, without having to clear everything through a central
packaging authority. So, there's a tremendous amount of flexibility as
to how you install things with EasyInstall, but that necessarily means
a lot of documentation is required to cover all scenarios well.
One thing I'll look into for future versions of EasyInstall, however,
is adding activated eggs to the beginning of sys.path instead of the
end, as that would possibly allow some even more flexible deployment
options, without needing to worry about conflicts from system packages.
Then, you could just set up a bin directory for a given project and
direct EasyInstall to install everything in that directory, without
needing to create a virtual Python.
Oliver Andrich
2005/9/19, Phillip J. Eby <p...@telecommunity.com>:
> [... lots of interesting text deleted ...]
> It's likely to take a good while before any major Linux or BSD
> distribution uses eggs as part of their standard installation and
> packaging. Right now, it's not even a "blessed" Python standard, and
> it would take a while for the distros to repackage their existing
> Python packages to fit.
at least the Linux and BSD distributions have already sophisticated
packaging systems available, that profit less from Easy Install then the
other users. Or better said, this will be, what they determine by
scratching on the highest level of Easy Install. I am honest. I also
thought about this that way until yesterday. Our discussion, TurboGears and
a lot of time over the day let me see some large benefits from using Easy
Install as a basis in distributions.
> Ultimately, EasyInstall is intended to empower the individual Python
> user and/or application to install the things they need, wherever they
> need them, without having to clear everything through a central
> packaging authority. So, there's a tremendous amount of flexibility as
> to how you install things with EasyInstall, but that necessarily means
> a lot of documentation is required to cover all scenarios well.
Install based installer in such a way, that Turbo Gears is more or less
self-contained? TurboGears could download all this packages to its own
site-package structure, then mangle some paths and everything is fine
without toughing the rest of the system? This would be great and from my
point of view this is a very good way to go. If I have understood this
correctly, and after seeing some other mails concerning installation
problems, may be Kevin can put this on his large
TurboGears-wish-list-composed-of-important-wishes. :)
At the end of this mail I like to talk a little about why I am so much
interested in this issue and topic. I am currently developing a web app
using Python, that is a news agency receiver for print newspapers. This
will be a product we use ourselves, but we will also sell it to customers.
The current product is a mess composed of PHP, Perl, and stuff. Secondly,
we are a Java minded company, but Java is also horrible for web apps in my
opinion. So, the solution I produce must install like a charm compared to
the existing product, and it must of course be lighter and easier then a
Java solution. :) As someone said, no one got fired dumbing a Java project,
but with Python this can be a different story. Luckily, I am also the team
manager for the development team, so the risc is a little bit minimized. :)
bon...@gmail.com
be very smart and download package as needed(from various sources), the
problem is :
1. not everyone has 24/7 internet link(and sometimes firewall may block
things)
2. the source is distributed and the link specified in it can come and
go(see problem about kid).
(2) is the biggest issue. Without a central repository, it is very hard
to solve. Perl at least maintain a central CPAN repository so once a
package is released, it will be there.
Oliver Andrich
> be very smart and download package as needed(from various sources), the
> problem is :
>
> 1. not everyone has 24/7 internet link(and sometimes firewall may block
> things)
install. May be by specifying a local path on the command line? Here I
hope Kevin or Phillip jump in as I am obviously not an Easy Install
sage.
> 2. the source is distributed and the link specified in it can come and
> go(see problem about kid).
>
> (2) is the biggest issue. Without a central repository, it is very hard
> to solve. Perl at least maintain a central CPAN repository so once a
> package is released, it will be there.
for. And face it, the Python community is not yet as big as the Perl
community. So, the way it works, is quite okay for a start. I have
experienced that something like central repos come easily as soon, as
something like Easy Install is a standard.
But coming back to the actual topic of this email, I also noted your
other email about packing systems on top of packing systems. As I am
using a Fedora Linux and you are using a Debian Linux, we are both
facing the same problem. I see two solutions for that:
a) We send Kevin some documentation he can put online for a setup
procedure on Fedora Core and Debian Sarge. This requires we package
the software that TurboGears requires as far as needed.
or
b) We talk Kevin into doing a self contained installation of
TurboGears. For me disk space is by no means an issue, so I can
perfectly live with every TurboGears installation requiring some X
megabytes.
As I am a lazy guy and I also love self contained installations for
some certain kinds of software or systems, I would personally prefer
b).
Regards,
bon...@gmail.com
from various source that IMO is the biggest issue. I have full root
access because I am running vserver and can have as many seperate
rootfs system as I want. I use /usr/local as the "local" system outside
debian's system so it is still a share by all user setup, on top of
debian(sort of).
I know having a CPAN equivalent is impossible at the moment. The next
best thing is to have Kevin maintains the tree, which is also why I
said unmanageable as it puts heavy burden on him.
I have seen the same thing in another linux project, openwrt on WRT54G.
It also use a similar buildroot system that grabs things incrementally
as needed and face the exact same problem of the source url can be
invalid in no time.
Actually, I have tried to comment out the setuptools style installation
in setup.py and all of the packages can install fine using the core
distutils. It is the actual usage of querying the pkg_resources in
TurboGears that stops me from doing it manually.
Ian Bicking
> (2) is the biggest issue. Without a central repository, it is very hard
> to solve. Perl at least maintain a central CPAN repository so once a
> package is released, it will be there.
CPAN. You can do it with setuptools (python setup.py upload), or
through the web interface. However, the listed maintainer for each
project would have to upload the package. Hopefully in the future, by
convention, people will all use the Cheese Shop, like Perl users all use
CPAN (also by convention). But if you want to jumpstart that by
submitting bugs to all effected projects, that's cool too (all my
projects will be uploading to Cheese Shop in the future, e.g.:
http://cheeseshop.python.org/pypi/SQLObject/0.7b1).
--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org
Kevin Dangoor
now, so part of the reason the TurboGears dependencies all appear on
the TurboGears download page is that CherryPy and SQLObject had not
yet made releases of the versions I was using. That, and I started
packaging things up as eggs myself before any of these projects were.
I fully intend to remove the packages from the TurboGears download
page as soon as I can be sure that Windows and Mac users can get the
correct versions of the software without needing a working C compiler.
I'll assume Linux users have a C compiler, but they just need the
correct versions of things.
Does the Cheeseshop maintain older versions of the software? That's
the other thing... TurboGears will need to have access to versions of
the packages that are known to work, until a newer release is checked
out.
Kevin
Phillip J. Eby
> Does the Cheeseshop maintain older versions of the software? That's
> the other thing... TurboGears will need to have access to versions of
> the packages that are known to work, until a newer release is checked
> out.
It keeps them, but EasyInstall won't find them if the package author
doesn't "unhide" the older versions; PyPI hides older versions by
default. They're still there, so if you linked to them with download
URLs on your project page they'll still be able to be found.
(Unless of course the package author deletes the release from PyPI, of
course.)
Kevin Dangoor
> It keeps them, but EasyInstall won't find them if the package author
> doesn't "unhide" the older versions; PyPI hides older versions by
> default. They're still there, so if you linked to them with download
> URLs on your project page they'll still be able to be found.
>
> (Unless of course the package author deletes the release from PyPI, of
> course.)
have all of the packages listed on the TurboGears download page. Odds
are that the package author won't delete all of the old releases, so
linking to PyPI for download may be fine. Not a big deal at this point
to have the packages on turbogears.org as well...