Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Shannon -jj Behrens

On 3/4/07, Christoph Haas [EMAIL PROTECTED] wrote:

 Dear list,

 I'm spending some of my spare time as a Debian developer which means
 creating Debian (binary) packages from software. In Debian you don't use
 easy_install to install Python modules but rely on packages that the
 distribution provides. E.g. to install Pylons and all it's dependencies
 you issue an aptitude install python-pylons which means that certain
 other packages are installed automatically:

 python
 python-routes
 python-myghty
 python-paste
 python-pastedeploy
 python-pastescript
 python-formencode
 python-simplejson
 python-webhelpers
 python-nose
 python-beaker

 Naturally I wondered how to properly deploy a self-made Pylons application
 on Debian. Perhaps someone with more insight of the Paster deployment
 process can help understand what's going on and whether that can be
 scripted to make it a Debian package. Or perhaps other readers who are
 familiar with Debian package have an idea, too?

 I could imagine a tool like pylons-buildpackage which creates a Pylons
 application and makes a proper Debian package of it that can be
 apt-installed. I'm eager to hear other people's ideas on that.

 For those not being involved into Debian package management: a Debian
 package takes the (upstream) software itself (usually a
 software-1.0.tar.gz file) and adds a special debian/ subdirectory that
 contains control information on the page. Such information deals with
 copyright, what other packages are needed (as stated above), which files
 are to be put where in the file system and a Makefile/shell script that is
 run to make the software (like ./configure; make; make install).

 I'm also interested in how other Debian users deploy Pylons applications.
 Do you just copy the project directory onto another computer? Or do you
 deploy into /usr/local? Or am I the only one using Debian here? :)

We're on Ubuntu, and we just use eggs.

-jj

-- 
http://jjinux.blogspot.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Piotr Ozarowski
Piotr Ozarowski wrote:
 # creating new Pylons app.
 $ paster create --template=pylons helloworld

 # creating Egg (f.e. for Windows users)
 $ python setup.py bdist_egg # will create an Egg in dist dir

 # creating debian package
 $ zcat ../helloworld_0.0.0dev-1.diff.gz | patch -p1  # see attachment
 $ debuild

and (as promised on #debian-python) here's pure debhelper version

(init.d script is still missing)

To Pylons ML readers: here's CDBS one:
http://lists.debian.org/debian-python/2007/03/bin0.bin

If you're using pkg_resources(), add python-setuptools to Depends:
(and other used dependencies, like: python-elixir, python-mako, ...)
-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


helloworld_0.0.0dev-1.diff.gz
Description: application/gunzip


pgpdazftrFshC.pgp
Description: PGP signature


Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread James Gardner

Hi Christoph,

I use Debian and the way I deploy my apps is using a virtual Python 
installation into a user account I setup for each app. I usually then 
just checkout the latest source code and run:

~/bin/python setup.py develop

The problem with trying to package up a Pylons app into a Debian package 
is that you have to worry about all the dependencies. You could package 
up all the dependencies too but that would be a pain.

I suppose the alternative solution if you really want to use a Debian 
package is to setup workingenv and then make a package out of the entire 
workingenv directory with the dependencies included as part of the one 
package.

I've always been happy to stick to using easy_install and eggs myself 
but when packages have C extensions the benefits of creating .debs 
become more apparent.

Also it is useful to have different packages available to different 
Pylons apps and if you just use .debs to install software into the main 
Python directories you can't do that.

I'd be interested to hear if you come up with a good solution though?

Cheers,

James

Christoph Haas wrote:
 Dear list,
 
 I'm spending some of my spare time as a Debian developer which means 
 creating Debian (binary) packages from software. In Debian you don't use 
 easy_install to install Python modules but rely on packages that the 
 distribution provides. E.g. to install Pylons and all it's dependencies 
 you issue an aptitude install python-pylons which means that certain 
 other packages are installed automatically:
 
 python
 python-routes
 python-myghty
 python-paste
 python-pastedeploy
 python-pastescript
 python-formencode
 python-simplejson
 python-webhelpers
 python-nose
 python-beaker
 
 Naturally I wondered how to properly deploy a self-made Pylons application 
 on Debian. Perhaps someone with more insight of the Paster deployment 
 process can help understand what's going on and whether that can be 
 scripted to make it a Debian package. Or perhaps other readers who are 
 familiar with Debian package have an idea, too?
 
 I could imagine a tool like pylons-buildpackage which creates a Pylons 
 application and makes a proper Debian package of it that can be 
 apt-installed. I'm eager to hear other people's ideas on that.
 
 For those not being involved into Debian package management: a Debian 
 package takes the (upstream) software itself (usually a 
 software-1.0.tar.gz file) and adds a special debian/ subdirectory that 
 contains control information on the page. Such information deals with 
 copyright, what other packages are needed (as stated above), which files 
 are to be put where in the file system and a Makefile/shell script that is 
 run to make the software (like ./configure; make; make install).
 
 I'm also interested in how other Debian users deploy Pylons applications. 
 Do you just copy the project directory onto another computer? Or do you 
 deploy into /usr/local? Or am I the only one using Debian here? :)
 
 Kindly
  Christoph
 
  


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Mike Orr

On 3/5/07, Shannon -jj Behrens [EMAIL PROTECTED] wrote:

 On 3/4/07, Christoph Haas [EMAIL PROTECTED] wrote:
  I'm also interested in how other Debian users deploy Pylons applications.
  Do you just copy the project directory onto another computer? Or do you
  deploy into /usr/local? Or am I the only one using Debian here? :)

 We're on Ubuntu, and we just use eggs.

Another Ubuntu user here.  (Though some of my computers are still on Gentoo.)

Ultimately the Python community and Linux distributors have to agree
on how to repackage eggs in their distribution format.  At the PyCon
session we didn't get any farther than this is a problem, and noted
that there are disadvantages as well as advantages of using eggs in
distributions, not to mention the multiplicity of formats a distro
would have to accommodate: Python eggs, Ruby Gems, Java JARs, Perl
whatevers.  I'm not sure it's worth trying to solve this ourselves as
Pylons users.

For personal/organizational applications, distributing eggs is much
easier than making an OS package.  Rsync'ing the application directory
to the server is easier still.  Deploying a zipped egg is a compromise
between the two.  Though copying a zipped egg doesn't update its
dependencies, so you'd have to do that manually or reinstall the egg
(ugh).

For distributing Pylons applications publicly, an egg is still easier
at this stage.  One problem is documentation, which is not included in
eggs.  Either egg developers should start including them as data
files, or eggs need a separate documentation category.  In the
meantime there's an argument for distributing the source tarball
instead of an egg, and installing it in development mode, because that
keeps the code and docs together.

If in fact there will be any publicly-distributed Pylons applications
that aren't just examples.

Unfortunately not all distros have gotten the local site-packages
directory distinct from the OS's site-packages directory concept yet.
 So one must either install into the global site-packages or use
virtual python or workingenv.  I'm leaning toward virtual python as
the most foolproof and auditable.

Theoretically eggs should declare all their dependencies.  This leads
to duplicate libraries if the same library is installed at the OS
level.  Organizations can determine a standard set of libraries
maintained at the OS level that will be excluded from local eggs.
This won't work with publicly-distributed eggs of course.  But if the
sysadmin has a local site-packages directory and installs libraries
there as eggs, easy_installing the application egg would skip
reinstalling the library.  But just copying a zipped egg will not
update its dependencies, so there's the hassle of reinstalling it in
case its dependencies have changed.

So there's not really one way to do it.

-- 
Mike Orr [EMAIL PROTECTED]

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Mike Orr

On 3/5/07, James Gardner [EMAIL PROTECTED] wrote:

 Hi Christoph,

 I use Debian and the way I deploy my apps is using a virtual Python
 installation into a user account I setup for each app. I usually then
 just checkout the latest source code ...

I see your version-control system isn't behind a firewall. :)

-- 
Mike Orr [EMAIL PROTECTED]

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Christoph Haas

On Monday 05 March 2007 22:29, Ian Bicking wrote:
 Christoph Haas wrote:
  I could imagine a tool like pylons-buildpackage which creates a
  Pylons application and makes a proper Debian package of it that can be
  apt-installed. I'm eager to hear other people's ideas on that.

 FWIW, I think such an installer should package up all the libraries in
 one Debian package, I imagine laid out something like:

/usr/lib/some-pylons-app/lib/python/(bunch of eggs)

I don't believe it would make things easier. All components like 
python-sqlalchemy, python-mako, python-webhelpers or python-pylons are 
already packaged for Debian. If by all the libraries you mean these 
packages it would create a second installation of them on a system which 
is not desirable. It would be best if the Pylons user who is about to 
create a Debian package sets up the proper (Debian-)dependencies in the 
debian/control file so just the Pylons project itself needs to be 
packaged.

 I use workingenv and a workingenv requirements file, and some shell
 scripts to do the setup from there.

I haven't worked with workingenv yet. Is it feasable to ship an application 
with all the needed dependencies into such a chroot and run them on a 
production system?

 Christoph

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Cliff Wells

On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote:

 But installing anything using easy_install - and be it just 
 into /usr/local - is chaotic and hard to control. easy_install cannot even 
 remove software properly. So I don't think I would want anything than a 
 binary deb package on my system. Just as a side note to Shannon Behrens 
 who said We're on Ubuntu, and we just use eggs. If you really just 
 install eggs instead of proper binary packages then your Ubuntu package 
 management will get into trouble in no time. (For those not familiar with 
 it: Ubuntu is a sister project of Debian and uses the same package 
 format.)

Why is this so?  I don't use Ubuntu (rather Gentoo and Fedora), but the
problem is mostly the same.  Frankly I tend to avoid all distro-provided
Python packages and use easy_install exclusively.  I think there might
be issues mixing the two methods, but I'm not entirely clear how
selecting easy_install *exclusively* over the system package manager
makes anything worse.


I will note that there are two main reasons I prefer easy_install: 

1) The packages provided by most distros tends toward the stale side and
tend to be far less inclusive than the Cheeseshop.  This means that *no
matter what* I'd be forced to use easy_install on some packages at some
point.  If anything is going to cause issues, it's *mixing* easy_install
with apt/rpm/emerge/etc.  Were I to choose using the system package
manager I'd have a rather smallish selection of slightly (or badly)
out-of-date packages with no obvious benefit in exchange for this
sacrifice. Given that this is the case, selecting to use easy_install
exclusively appears to be a no-brainer.

2) For my specific environments, I utilize user-owned site-packages
directories (which helps with maintaining version compatibility for
deployed applications and allows users to install/maintain their own
required packages).  This is probably not possible using the system
packaging tools.

I'll add that while it's true that easy_install cannot remove packages
properly, doing so manually is hardly problematic (remove the .egg and
its corresponding entry from easy_install.pth).  This doesn't resolve
dependency issues, but frankly those aren't nearly as much of an issue
with Python as they are at the OS level (simply by nature of Python's
more limited scope and influence on the system at large).

Regards,
Cliff



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Piotr Ozarowski
[Cliff Wells, 05.03.2007]
 
 On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote:
 
  But installing anything using easy_install - and be it just 
  into /usr/local - is chaotic and hard to control. easy_install cannot even 
  remove software properly. So I don't think I would want anything than a 
  binary deb package on my system. Just as a side note to Shannon Behrens 
  who said We're on Ubuntu, and we just use eggs. If you really just 
  install eggs instead of proper binary packages then your Ubuntu package 
  management will get into trouble in no time. (For those not familiar with 
  it: Ubuntu is a sister project of Debian and uses the same package 
  format.)
 
 Why is this so?

You can install your Pylons app. and forget about dependencies for next 2 years.
Package maintainers will fix all bugs in related packages.

Sure, developers like ez_install. System administrators don't!

-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgpyit1Asp71B.pgp
Description: PGP signature


Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Ian Bicking

Christoph Haas wrote:
 Of course I understand that many people find easy_install a good and simple 
 way to install Python packages. But it will destabilize an operating 
 system that keeps track of what's installed. It may be no problem on 
 Windows where you reinstall after a few months anyway. But my Debian 
 system has been installed years ago and just upgraded with the time. I 
 wouldn't want to have cruft flying around. Especially since there is no 
 sane way to get of software I easy_install'ed.
 
 So I disagree with your opinion that Python-related software that is 
 shipped through easy_install should blindly be used on any system. If 
 that's what you wanted to express.

You shouldn't install into system areas with easy_install -- you should 
use some kind of isolated environment like workingenv, virtual-python, 
or zc.buildout.

-- 
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Cliff Wells

On Mon, 2007-03-05 at 23:42 +0100, Piotr Ozarowski wrote:
 [Cliff Wells, 05.03.2007]
  
  On Mon, 2007-03-05 at 22:29 +0100, Christoph Haas wrote:
  
   But installing anything using easy_install - and be it just 
   into /usr/local - is chaotic and hard to control. easy_install cannot 
   even 
   remove software properly. So I don't think I would want anything than a 
   binary deb package on my system. Just as a side note to Shannon Behrens 
   who said We're on Ubuntu, and we just use eggs. If you really just 
   install eggs instead of proper binary packages then your Ubuntu package 
   management will get into trouble in no time. (For those not familiar with 
   it: Ubuntu is a sister project of Debian and uses the same package 
   format.)
  
  Why is this so?
 
 You can install your Pylons app. and forget about dependencies for next 2 
 years.
 Package maintainers will fix all bugs in related packages.

There is almost zero chance of that happening in the Python world, no
matter who's working on it.  In fact, if I install a Pylons app written
around Pylons 0.9.x, it's almost guaranteed that letting the system
package manager update Pylons will break that app at some point in the
not-so-distant future (in fact this exact issue around TurboGears was
the very reason I moved solely to easy_install).

This problem isn't Python-specific either.  You'll note that almost all
Ruby users use gem to install packages as well.  I've also found that
PHP does better when using PEAR for the most part.  

The single exception I've found where the system packaging tools do a
better job is when there are C extensions involved (and hence a reliance
on system libraries and a dependency tree that might fork outside the
realm of Python and easy_install).

 Sure, developers like ez_install. System administrators don't!

That's odd, because I do equal parts of both and greatly prefer
easy_install.  On my shared hosting boxes, I can use easy_install to
maintain specific versions of Python packages as required by specific
applications for specific users, something not easily doable (or doable
at all) using the system packaging tools.

Note that I'm not suggesting that for *some* people using the system
tools might not be preferable to easy_install nor that pursuing the
packaging of Python libraries and apps as debs/rpms/ebuilds or whatever
is a waste.  I am, however, contesting the blanket assertions that using
easy_install leads to chaos (it doesn't) or that system administrators
prefer the system tools over easy_install (this is pure speculation
based on the assumption that the sysadmin is clueless about
easy_install/gems/PEAR/cpan/et al).  

Regards,
Cliff



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Piotr Ozarowski
[Cliff Wells, 05.03.2007]
 On Mon, 2007-03-05 at 23:42 +0100, Piotr Ozarowski wrote:
  You can install your Pylons app. and forget about dependencies for next 2 
  years.
  Package maintainers will fix all bugs in related packages.
 
 There is almost zero chance of that happening in the Python world, no
 matter who's working on it.

Gaupol package (subtitle editor) will be shipped with version 0.7.1 in
Debian Etch. This version does not work with new PyGTK. I, as a package
maintainer, will make sure [1] that even if someone decides to upload new
PyGTK, Gaupol users will have working app.

[1] by applying fix from 0.7.2 or forcing new upstream into Etch

 In fact, if I install a Pylons app written
 around Pylons 0.9.x, it's almost guaranteed that letting the system
 package manager update Pylons will break that app at some point in the
 not-so-distant future (in fact this exact issue around TurboGears was
 the very reason I moved solely to easy_install).

package maintainer will not upload new upstream version to stable
(production) distribution. So if you created your app with 0.9.x and
distribution contains Pylons 0.9.x - you don't have to worry.

  Sure, developers like ez_install. System administrators don't!
 
 That's odd, because I do equal parts of both and greatly prefer
 easy_install.  On my shared hosting boxes, I can use easy_install to
 maintain specific versions of Python packages as required by specific
 applications for specific users, something not easily doable (or doable
 at all) using the system packaging tools.

You know Python, you know how to fix bugs in apps written in Python.

Now, lets imagine this: User does not know Python and Pylons at all, he
does not follow sqlalchemy, routes, etc. mailing lists and thus will not
be aware of security bugs in these modules. He just saw an outstanding
app. on a website and decided to install it on his server. He's
regularly updating his system, because he knows that if there will be a
serious bug discovered in one of his apps or in one of dependencies -
update will be available soon. He don't need new fancy version, all he
wants is working app. Will you still recommend him to install this app.
with ez_install?

Now lets say there's new stable version of distribution he uses and our
User decides to dist-upgrade to the new version. Will you recommend him
to do this upgrade with ez_install? Will you tell him to remove old app
first? Will you tell him to reinstall his system first? Will x (and x is
a lot) users test this upgrade first?

 Note that I'm not suggesting that for *some* people using the system
 tools might not be preferable to easy_install nor that pursuing the
 packaging of Python libraries and apps as debs/rpms/ebuilds or whatever
 is a waste.  I am, however, contesting the blanket assertions that using
 easy_install leads to chaos (it doesn't) or that system administrators
 prefer the system tools over easy_install (this is pure speculation
 based on the assumption that the sysadmin is clueless about
 easy_install/gems/PEAR/cpan/et al).

I have no idea how gems work, but I still want to use apps written in
Ruby. Will you tell me to learn how to use them? (Please note that I
already know how to use debs)

My point is: not everyone wants newest software. Some people want
*stable* software and there are lots of system administrators among them.


PS I really should be sleeping now :-(
-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgp49IKdFUBHF.pgp
Description: PGP signature


Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Stephen F. Steiner

On Mar 5, 2007, at 8:08 PM, Piotr Ozarowski wrote:

 PS I really should be sleeping now :-(

Yes, you should but you really raise some valid points even in your  
altered state ;-).

S

Stephen F. Steiner
Integrated Development Corporation
[EMAIL PROTECTED]
www.integrateddevcorp.com
(603)433-1232






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Deplyoing Pylons applications as Debian packages?

2007-03-05 Thread Ian Bicking

Piotr Ozarowski wrote:
 Now, lets imagine this: User does not know Python and Pylons at all, he
 does not follow sqlalchemy, routes, etc. mailing lists and thus will not
 be aware of security bugs in these modules. He just saw an outstanding
 app. on a website and decided to install it on his server. He's
 regularly updating his system, because he knows that if there will be a
 serious bug discovered in one of his apps or in one of dependencies -
 update will be available soon. He don't need new fancy version, all he
 wants is working app. Will you still recommend him to install this app.
 with ez_install?

The *application* can be shipped as a package without shipping lots of 
individual libraries.  The application package should contain all the 
libraries that are not already in Debian, and perhaps some of the 
libraries that already are in Debian if something has been 
inappropriately packaged.  That is, there's *no* way that Mako is at a 
point when it should be released as a package (or quite a few of the 
packages used in a typical Pylons application).  But an *application* 
can still be stable despite that, because the application only uses the 
areas of the library that are stable.  However, you should never force 
newer packages to use an old version of an unstable library just because 
someone else used it previously; nor should you force a potentially 
difficult upgrade and repackaging of the application because of a 
library upgrade that wouldn't effect it.

Users who don't know Python or Pylons don't install Python or Pylons 
libraries, they install applications, and those applications can and 
should be largely self-contained when installed.  Users who do know 
Python and Pylons and want to hack on software shouldn't use Debian 
packages.

-- 
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---