Packaging web2py for Debian

[José L.]

Hi, as it seems that time goes by, and no available packages for
Debian are ready, I'm going to begin to work on it seriously to upload
web2py to Debian.
I know ( http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d713bdd8/252d25418aeb42fd
) Mark told he was going to work on it, but I think that I have been
patient enough waiting since April. It's not only Debian is one of the
most important Linux distribution, also many other distributions as
Ubuntu are derivatives from Debian, so uploading web2py to Debian will
bring it to many users in the Linux world.

I'd like to have a package similar to the django one. There is a
python-django package, and I'd like to make a python-web2py package to
work in a similar way, so people don't need to relearn a new method of
work.
I'd like it to work as similar as possible to
http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/ .

So, the main question for me is:
once gluon is installed in the PYTHONPATH and web2py.py installed in /
usr/bin, I would like to be able to tell the user:
execute python web2py.py in any directory and point your browser to
http://localhost:8000 to begin to work.

But, as web2py structure is today, I don't know if such thing is
possible (after adding every needed file to every needed path).

If not, what other approaches might be used to make any user in the
system able to use a system with a installed web2py structure?


On the other hand, if more people want to collaborate in the packaging
I'll be glad to open a project in alioth.debian.org, so we can work
together.

Regards.
José L.

[mdipierro]

web2py -f folder

It should work but you may want to check. Perhaps we may need a patch.

Massimo

On Oct 13, 1:55 pm, José L. <jredr...@gmail.com> wrote:
> Hi, as it seems that time goes by, and no available packages for
> Debian are ready, I'm going to begin to work on it seriously to upload
> web2py to Debian.

> I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...

> ) Mark told he was going to work on it, but I think that I have been
> patient enough waiting since April. It's not only Debian is one of the
> most important Linux distribution, also many other distributions as
> Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> bring it to many users in the Linux world.
>
> I'd like to have a package similar to the django one. There is a
> python-django package, and I'd like to make a python-web2py package to
> work in a similar way, so people don't need to relearn a new method of
> work.
> I'd like it to work as similar as possible tohttp://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> So, the main question for me is:
> once gluon is installed in the PYTHONPATH and web2py.py installed in /
> usr/bin,  I would  like to be able to tell the user:

> execute python web2py.py in any directory and point your browser tohttp://localhost:8000to begin to work.

[José L.]

On 13 oct, 21:00, mdipierro <mdipie...@cs.depaul.edu> wrote:
> web2py -f folder
>
> It should work but you may want to check. Perhaps we may need a patch.

I'll try it,
I guess some other files will be needed, but I'll report my progress.


Anyway maybe you could add some code to web2py.py so if it doesn't
find the gluon dir (or any other flag file) in the same directory it's
executed, it might pass automagically -f $HOME to the script.

Regards

[Michele Comitini]

Hi José,

The .deb is badly needed to spread web2py even more!

Would that be useful for ubuntu also which is probaly the most common
linux distro?

The packaging must also take into account that a machine could have
different instances of web2py.
It would be a good idea to have some tools in the .deb to support the
creation of different instances, maybe
through http://pypi.python.org/pypi/virtualenv so that upgrade of
system python doesn't break everything as it usually happens on
debian with other python frameworks.

mic

2010/10/13 José L. <jred...@gmail.com>:

[mdipierro]

I feel this will be a maintenance nightmare unless it somehow upgrades
itself. The release process of debian is very slow compared to ours.

On Oct 13, 3:12 pm, Michele Comitini <michele.comit...@gmail.com>
wrote:

> Hi José,
>
> The .deb is badly needed to spread web2py even more!
>
> Would that be useful for ubuntu also which is probaly the most common
> linux distro?
>
> The packaging must also take into account that a machine could have
> different instances of web2py.
> It would be a good idea to have some tools in the .deb to support the
> creation of different instances, maybe

> throughhttp://pypi.python.org/pypi/virtualenvso that upgrade of

> system python doesn't break everything as it usually happens on
>  debian with other python frameworks.
>
> mic
>

> 2010/10/13 José L. <jredr...@gmail.com>:

>
> > Hi, as it seems that time goes by, and no available packages for
> > Debian are ready, I'm going to begin to work on it seriously to upload
> > web2py to Debian.

> > I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...

> > ) Mark told he was going to work on it, but I think that I have been
> > patient enough waiting since April. It's not only Debian is one of the
> > most important Linux distribution, also many other distributions as
> > Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> > bring it to many users in the Linux world.
>
> > I'd like to have a package similar to the django one. There is a
> > python-django package, and I'd like to make a python-web2py package to
> > work in a similar way, so people don't need to relearn a new method of
> > work.
> > I'd like it to work as similar as possible to
> >http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> > So, the main question for me is:
> > once gluon is installed in the PYTHONPATH and web2py.py installed in /
> > usr/bin,  I would  like to be able to tell the user:
> > execute python web2py.py in any directory and point your browser to

> >http://localhost:8000to begin to work.

[Richard]

I remember talk about ability to upgrade through admin - is that
practical?

On Oct 14, 7:29 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I feel this will be a maintenance nightmare unless it somehow upgrades
> itself. The release process of debian is very slow compared to ours.
>
> On Oct 13, 3:12 pm, Michele Comitini <michele.comit...@gmail.com>
> wrote:
>
> > Hi José,
>
> > The .deb is badly needed to spread web2py even more!
>
> > Would that be useful for ubuntu also which is probaly the most common
> > linux distro?
>
> > The packaging must also take into account that a machine could have
> > different instances of web2py.
> > It would be a good idea to have some tools in the .deb to support the
> > creation of different instances, maybe

> > throughhttp://pypi.python.org/pypi/virtualenvsothat upgrade of

> > system python doesn't break everything as it usually happens on
> >  debian with other python frameworks.
>
> > mic
>
> > 2010/10/13 José L. <jredr...@gmail.com>:
>
> > > Hi, as it seems that time goes by, and no available packages for
> > > Debian are ready, I'm going to begin to work on it seriously to upload
> > > web2py to Debian.
> > > I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...
> > > ) Mark told he was going to work on it, but I think that I have been
> > > patient enough waiting since April. It's not only Debian is one of the
> > > most important Linux distribution, also many other distributions as
> > > Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> > > bring it to many users in the Linux world.
>
> > > I'd like to have a package similar to the django one. There is a
> > > python-django package, and I'd like to make a python-web2py package to
> > > work in a similar way, so people don't need to relearn a new method of
> > > work.
> > > I'd like it to work as similar as possible to
> > >http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> > > So, the main question for me is:
> > > once gluon is installed in the PYTHONPATH and web2py.py installed in /
> > > usr/bin,  I would  like to be able to tell the user:
> > > execute python web2py.py in any directory and point your browser to

> > >http://localhost:8000tobegin to work.

[Tim Michelsen]

> I feel this will be a maintenance nightmare unless it somehow upgrades
> itself. The release process of debian is very slow compared to ours.

You can have automatic daily builds of a source tree import to your PPA:
https://help.launchpad.net/Packaging/SourceBuilds/Recipes

[mdipierro]

the fact is... where is web2py going to reside? where are the apps
going to be? What will be the permissions?
Perhaps we should just provide a function like

web2py deploy [where]
web2py start [where]
web2py stop [where]
web2py upgrade [where]

which some other options like
--use apache
--use lighttpd
--use uwsgi

and let the deploy function download the latest web2py.

On Oct 13, 4:17 pm, Richard <richar...@gmail.com> wrote:
> I remember talk about ability to upgrade through admin - is that
> practical?
>
> On Oct 14, 7:29 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > I feel this will be a maintenance nightmare unless it somehow upgrades
> > itself. The release process of debian is very slow compared to ours.
>
> > On Oct 13, 3:12 pm, Michele Comitini <michele.comit...@gmail.com>
> > wrote:
>
> > > Hi José,
>
> > > The .deb is badly needed to spread web2py even more!
>
> > > Would that be useful for ubuntu also which is probaly the most common
> > > linux distro?
>
> > > The packaging must also take into account that a machine could have
> > > different instances of web2py.
> > > It would be a good idea to have some tools in the .deb to support the
> > > creation of different instances, maybe

> > > throughhttp://pypi.python.org/pypi/virtualenvsothatupgrade of

> > > system python doesn't break everything as it usually happens on
> > >  debian with other python frameworks.
>
> > > mic
>
> > > 2010/10/13 José L. <jredr...@gmail.com>:
>
> > > > Hi, as it seems that time goes by, and no available packages for
> > > > Debian are ready, I'm going to begin to work on it seriously to upload
> > > > web2py to Debian.
> > > > I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...
> > > > ) Mark told he was going to work on it, but I think that I have been
> > > > patient enough waiting since April. It's not only Debian is one of the
> > > > most important Linux distribution, also many other distributions as
> > > > Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> > > > bring it to many users in the Linux world.
>
> > > > I'd like to have a package similar to the django one. There is a
> > > > python-django package, and I'd like to make a python-web2py package to
> > > > work in a similar way, so people don't need to relearn a new method of
> > > > work.
> > > > I'd like it to work as similar as possible to
> > > >http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> > > > So, the main question for me is:
> > > > once gluon is installed in the PYTHONPATH and web2py.py installed in /
> > > > usr/bin,  I would  like to be able to tell the user:
> > > > execute python web2py.py in any directory and point your browser to

> > > >http://localhost:8000tobeginto work.

[Michele Comitini]

+1
the package could be web2py installation manager (a debconf launched
by "dpkg --reconfigure web2py") and add dependencies
like a system python and needed modules.

2010/10/14 mdipierro <mdip...@cs.depaul.edu>:

[Martin.Mulone]

On 13 oct, 18:17, Richard <richar...@gmail.com> wrote:
> I remember talk about ability to upgrade through admin - is that
> practical?
>

In production with wsgi-apache2 is not practical.

A dream if I can do in the server: sudo apt-get update, sudo apt-get
upgrade.
The process of debian is very slow, perhaps a ppa. And I think this is
important for new users.

[Mark Breedveld]

Hello Guys,

My apologise for my late update on the project.
Had to get my propedeuse :p.

And next 1 - 1,5 year I hope to do my graduation project on HRO.
Which I hope is implement or extends web2py manager.

In other topics we discussed the complexity and problems.
Some of us agreed that we would make an application that maintains the
web2py instances.

I've set up some main features. (MoSCoW)
- The application must be cross-platform too keep it maintainable for
us.
- The application must be run by its own user or the system user
- The application could support the multiple connectors
- The application could check/install/config on multiple platforms
multiple depencies like database/frontend servers

This is very hard too accomplish. And that's why I want too spend a
hole year on it.

If is was only for Ubuntu, I would have "stolen" mdipierro update
application and changed it slightly into a separate application. Asked
if someone here put it in the Ubuntu repository. Still a possibility
for the 2 years which it takes to the final version. If I get there at
all. I'm still a junior and a student:p.

Next week I hope too give you all the application overview, so we can
discuss it.

greetings and another apologise,

Mark Breedveld,
www.markbreedveld.nl

P.s. mdipierro, would it be possible too do the graduation project as
an exchange student at the DePaul University in Chicago. (I would like
too hear your answer off-topic)

[José L.]

On 13 oct, 22:29, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I feel this will be a maintenance nightmare unless it somehow upgrades
> itself. The release process of debian is very slow compared to ours.
>

Yes and not. Debian is three distributions: stable, testing and sid.
If you want to run sid, you have the most upgraded distribution in the
world.


The web2py package in stable must be stable, i.e. it must not change,
except for security patches. Even if it's two years old, it must be
work. I don't think it should be a nightmare if web2py changelog
explicits says when a security fix is applied.
This would allow a web2py application installed in a stable Debian
machine can run for years, without worrying if a new change in the
latest web2py release would break the compatibility.
Also, this would allow some new "applications" built over web2py could
be added to the Debian repository, just adding python-web2py as a
dependency.

I've been using web2py for about a year, and some of my applications
are running a 10 months web2py version without any problem, and I
don't plan to upgrade it. I feel happy using the new features of the
latest versions, but for new applications: that's what Debian testing
or Debian sid distributions are for.

> On Oct 13, 3:12 pm, Michele Comitini <michele.comit...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > Hi José,
>
> > The .deb is badly needed to spread web2py even more!
>
> > Would that be useful for ubuntu also which is probaly the most common
> > linux distro?
>
> > The packaging must also take into account that a machine could have
> > different instances of web2py.
> > It would be a good idea to have some tools in the .deb to support the
> > creation of different instances, maybe

> > throughhttp://pypi.python.org/pypi/virtualenvsothat upgrade of

> > system python doesn't break everything as it usually happens on
> >  debian with other python frameworks.
>
> > mic
>
> > 2010/10/13 José L. <jredr...@gmail.com>:
>
> > > Hi, as it seems that time goes by, and no available packages for
> > > Debian are ready, I'm going to begin to work on it seriously to upload
> > > web2py to Debian.
> > > I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...
> > > ) Mark told he was going to work on it, but I think that I have been
> > > patient enough waiting since April. It's not only Debian is one of the
> > > most important Linux distribution, also many other distributions as
> > > Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> > > bring it to many users in the Linux world.
>
> > > I'd like to have a package similar to the django one. There is a
> > > python-django package, and I'd like to make a python-web2py package to
> > > work in a similar way, so people don't need to relearn a new method of
> > > work.
> > > I'd like it to work as similar as possible to
> > >http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> > > So, the main question for me is:
> > > once gluon is installed in the PYTHONPATH and web2py.py installed in /
> > > usr/bin,  I would  like to be able to tell the user:
> > > execute python web2py.py in any directory and point your browser to

> > >http://localhost:8000tobegin to work.

[José L.]

On 13 oct, 23:17, Richard <richar...@gmail.com> wrote:
> I remember talk about ability to upgrade through admin - is that
> practical?
>

It works, but it must be disabled in the Debian package. Versions can
not be upgraded without upgrading the package, that would break the
system packages database. As an example, OpenOffice or firefox have
that same feature disabled in their Debian packages. If you want to
upgrade the application you have to upgrade the package.

[José L.]

Debian backports provide a much safer upgrading. I won't like to trust
my server installation in a daily built package. I'd prefer using a
stable package, or if I want the latest feature, using a backports
that has already been checked and passed through a period of days
before being added to Debian testing from unstable.

[José L.]

On 14 oct, 02:36, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> Hello Guys,
>
> My apologise for my late update on the project.
> Had to get my propedeuse  :p.
>
> And next 1 - 1,5 year I hope to do my graduation project on HRO.
> Which I hope is implement or extends web2py manager.
>
> In other topics we discussed the complexity and problems.
> Some of us agreed that we would make an application that maintains the
> web2py instances.
>
> I've set up some main features. (MoSCoW)
> - The application must be cross-platform too keep it maintainable for
> us.
> - The application must be run by its own user or the system user
> - The application could support the multiple connectors
> - The application could check/install/config on multiple platforms
> multiple depencies like database/frontend servers
>
> This is very hard too accomplish. And that's why I want too spend a
> hole year on it.

That's not a packaging of an application for a distribution. What you
want to do doesn't exist and, as far as I know, has never being
integrated in a linux distribution.

I don't mean you must not do it, I just mean that I don't think your
work will be accepted in any distribution, but it may be useful as a
package to be downloaded from the web2py site. But, a package that
works is different from a package that can be accepted in the official
repository of a linux distribution.

[Mark Breedveld]

I've not so much time.
But we have done this discussion before.
There where three problems with packaging web2py.

- Really frequent release period (not impossible for someone with a
lot time)
- Difficult to implement according the packaging guidelines
- Difficult to implement with user separation
- (Too) many configuration possible

If we solve the above and find someone with enough time. Yes, that
would be perfect and I would support that.

The application I have in mind looks like webmin, ecplipse IDE (plugin
framework), netbeans (plugin framework). A kind of universal installer
for web2py. This situation would mean the web2py is plugin in the
system. Every plugin has its own capability's and configuration. like
- Apache ( wsgi+ web2py + mysql + jailroot )
- http ligth + web2py + postgres

But the first release would contain a simple plugin.
Just web2py in some folder under some user.

And the internal updater of web2py is used to update it.

But if you say that this is not allowed.
Then there is only one thing to do.
Find a company or person which has explicit benefit or/and willing to
contribute a large amount of time by packaging.
He/They would become the Release manager of web2py.

regards Mark,

[José L.]

On 14 oct, 17:24, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> I've not so much time.
> But we have done this discussion before.
> There where three problems with packaging web2py.
>
> - Really frequent release period (not impossible for someone with a
> lot time)

I've already answer this before: Debian sid for frequent uploads,
debian stable for stable servers (with security patches). The
frequency the package is updated will depend on how much web2py
changes between releases. With a good packaging it may take five
minutes recompiling the package. Also, if the packaging is done via a
group of people working together in alioth.debian.org it may be
updated very often.

> - Difficult to implement according the packaging guidelines

That's where I think I can help, with the help of others who know
better the internals of web2py to solve the problems that may arise.

> - Difficult to implement with user separation

It's related to the above problem, but I think it can be done.

> - (Too) many configuration possible

From my point of view the package only should provide one possible
configuration, the less intrusive (in terms of changing user
configurations): use the rocket server and sqlite. It may also provide
Readme or example files to configure apache, or other servers, but
that's something not needed to begin to work with web2py. Configuring
a server is done to put a server in production, and that's something
that, in my opinion, should always be done manually, not automatically
by installing a package.

>
> If we solve the above and find someone with enough time. Yes, that
> would be perfect and I would support that.
>
> The application I have in mind looks like webmin, ecplipse IDE (plugin
> framework), netbeans (plugin framework). A kind of universal installer
> for web2py. This situation would mean the web2py is plugin in the
> system. Every plugin has its own capability's and configuration. like
> - Apache ( wsgi+ web2py + mysql + jailroot )
> - http ligth + web2py + postgres
>
> But the first release would contain a simple plugin.
> Just web2py in some folder under some user.
>
> And the internal updater of web2py is used to update it.
>
> But if you say that this is not allowed.

It's not allowed as a Debian package inside Debian repositories, but
you can do a Debian package with it inside for your personal use, or
to put it in a web2py download page.

> Then there is only one thing to do.
> Find a company or person which has explicit benefit or/and willing to
> contribute a large amount of time by packaging.
> He/They would become the Release manager of web2py.
>

I think I don't understand what you mean or what you would like to do.
A package maintainer is not a release manager of the application. The
package maintainer always works with upstream, and after upstream has
released. It doesn't matter the way upstream releases, and, obviously,
the release manager must be some of the upstream team. The package
maintainer doesn't need to be part of the upstream team. He just pick
up the sources and make a package that fullfils the distribution
packaging guidelines. I want to have a Debian package of web2py, so I
volunteer to work on it, but I do not want to be part of the web2py
release team. I think Massimo is doing a great work with the help of
many people who know of Python and web development much more than me .
Also, I don't have any interest in releasing for Mac, windows, or even
Red Hat. I am just a Debian Developer who is using web2py, knows the
internal of packaging, has permissions to upload new software to the
official Debian repository, and would like to have it in Debian. So
far, so good. No more ambitions, no more needs.

Regards
José L.

[Mark Breedveld]

Well that makes a hope clear.
I learned a lot from your explanation.

You did rule out almost the obstacles.
And the last one should solve able.
Changing some process within web2py.

I need this for my project.
So if you need anything, please let me know.
Direct mail will grantee answer...

and all try to follow this topic.

Mark,

[Christopher Steel]

If your break things down into one or more “debian” packages and at
least one web2py application you could end up with a phenomenally
powerful and easy to maintain setup that could have resounding
repercussions, so to speak, for all parties.

How does the following example sound?

Package 1, web2py

sudo apt-get install web2py

unpacks a stable version of web2py to the users home directory if one
does not exist.

/home/mary/web2py/web2py

Adds scripts for starting, stopping and restarting web2py using the
web2py *built in* web server. An option to install to a directory
other than the “default” can be made available as well.

Advantages
- Always works
- Does not break anything, ever
- Easy to customize
- Highly portable
- Can start developing right away
- Easy to implement
- easy to clean up via apt-get purge and so on.
- easy to backup, delete, upgrade etc.

Disadvantages
- Might be hard to justify doing a dissertation on this, but using
Package X the sky is the limit ;)

Package X example, web2py universal installer

sudo apt-get install universal-web2py

If the web2py package is not installed it gets installed, if mercurial
is not already installed it gets installed. If a clone of the web2py
application called “universal installer” does not exist, it is created
in ${HOME}/web2py/web2py/applications. if web2py is not running it
starts it and opens default browser to the universal application.

The universal application can do almost anything you like then and you
would easily create additional packages and so forth in this way.

People who want a “server installer” can create a “server installer”
web2py application and /or debian package that could be made available
via your universal installer.

Sounds cool!

Cheers,

Christopher Steel

Voice of Access

[Jurgis Pralgauskis]

Maybe You could use
https://help.launchpad.net/Packaging/SourceBuilds/

if you'd create stable branch on bazar and add packaging recipy like
https://code.edge.launchpad.net/~mdipierro/web2py/devel/+new-recipe
from
https://code.edge.launchpad.net/~mdipierro/web2py/devel (notice
code.EDGE.launch...)

On 13 okt., 20:29, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I feel this will be a maintenance nightmare unless it somehow upgrades
> itself. The release process of debian is very slow compared to ours.
>
> On Oct 13, 3:12 pm, Michele Comitini <michele.comit...@gmail.com>
> wrote:
>
> > Hi José,
>
> > The .deb is badly needed to spread web2py even more!
>
> > Would that be useful for ubuntu also which is probaly the most common
> > linux distro?
>
> > The packaging must also take into account that a machine could have
> > different instances of web2py.
> > It would be a good idea to have some tools in the .deb to support the
> > creation of different instances, maybe

> > throughhttp://pypi.python.org/pypi/virtualenvsothat upgrade of

> > system python doesn't break everything as it usually happens on
> >  debian with other python frameworks.
>
> > mic
>
> > 2010/10/13 José L. <jredr...@gmail.com>:
>
> > > Hi, as it seems that time goes by, and no available packages for
> > > Debian are ready, I'm going to begin to work on it seriously to upload
> > > web2py to Debian.
> > > I know (http://groups.google.com/group/web2py/browse_thread/thread/45ea4327d7...
> > > ) Mark told he was going to work on it, but I think that I have been
> > > patient enough waiting since April. It's not only Debian is one of the
> > > most important Linux distribution, also many other distributions as
> > > Ubuntu are derivatives from Debian, so uploading web2py to Debian will
> > > bring it to many users in the Linux world.
>
> > > I'd like to have a package similar to the django one. There is a
> > > python-django package, and I'd like to make a python-web2py package to
> > > work in a similar way, so people don't need to relearn a new method of
> > > work.
> > > I'd like it to work as similar as possible to
> > >http://codeghar.wordpress.com/2007/12/01/django-in-ubuntu/.
>
> > > So, the main question for me is:
> > > once gluon is installed in the PYTHONPATH and web2py.py installed in /
> > > usr/bin,  I would  like to be able to tell the user:
> > > execute python web2py.py in any directory and point your browser to

> > >http://localhost:8000tobegin to work.

[Mark Breedveld]

You have the idea. Thanks for clearing it towards the others.

My guesses it we need to do both.
Because Jose goal is general purpose and mine aswell,
but comes with overkill in the most cases.

In Jose case I would suggest a slight change.
web2py-core
web2py-gluon

This has been discusses before, I recall you where in those
discussions Jose.
http://groups.google.com/group/web2py/browse_frm/thread/45ea4327d713bdd8/f4a9c8160432cfbb?hl=en&lnk=gst&q=debian#f4a9c8160432cfbb

http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb5270d/550ed09fbf7af9f2?hl=en&lnk=gst&q=debian#550ed09fbf7af9f2

There are some other topics, search for turnkeylinux, where this is
mentioned.

I recall Dimo Barsky was busy with packaging Gluon, but I've been out
for a while.
I don't know him, but he might help with this.

It was chaos post again, but I hope this one helps:p.

Mark,

[José L.]

On 14 oct, 23:51, Christopher Steel <chris.st...@gmail.com> wrote:
> If your break things down into one or more “debian” packages and at
> least one web2py application you could end up with a phenomenally
> powerful and easy to maintain setup that could have resounding
> repercussions, so to speak, for all parties.
>
> How does the following example sound?
>
> Package 1, web2py
>

In Debian it should be python-web2py

> sudo apt-get install web2py
>
>         unpacks a stable version of web2py to the users home directory if one
> does not exist.
>
>         /home/mary/web2py/web2py
>

I'm thinking of a script doing (similar to what python-django package
does):

cd /home/me/whatever/

web2py-admin startproject newprojectname

would create
/home/me/whatever/web2py
.............. ......./applications/newprojectname
......................./applications/admin (linking to /usr/share/
web2py/applications/admin)

....................../any needed stuff at web2py that needs to be
modified by the user and can not be in the PYTHONPATH or /usr/share/

web2py





> Adds scripts for starting, stopping and restarting web2py using the
> web2py *built in* web server. An option to install to a directory
> other than the “default” can be made available as well.

it could be just:
cd /home/me/web2py
python web2py

i.e. exactly as it is now.
I'm not sure if this process might be simplified more. One evident
simplification is adding a desktop menu entry calling web2py and
doing:

cd $HOME
if not exists, creates web2py/applications directory, and links admin
directory from /usr/share/web2py/applications/admin
launch web2py script
launc x-www-browser http://localhost:8900


So, the user can begin to work in the web browser without needing to
open a terminal window, whenever he wants to use web2py in its own
$HOME directory.

A pending question is how to deal with the needed writing permisions
in applications/admin/errors and application/admin/sessions
directories. If the directory admin is linked from /usr/share/web2py/
applications/admin, the current user doesn't have permissions there,
and should not have them if the computer is used by different users. A
way to allow each user have its own sessions and errors directories
for the admin application is needed.

>
> Advantages
> - Always works
> - Does not break anything, ever
> - Easy to customize
> - Highly portable
> - Can start developing right away
> - Easy to implement
> - easy to clean up via apt-get purge and so on.
> - easy to backup, delete, upgrade etc.

Fully agree, just upgrading the package the user benefits from the new
web2py code, including the admin or welcome applications, without
touching a line of his own applications.

>
> Disadvantages
> - Might be hard to justify doing a dissertation on this, but using
> Package X the sky is the limit ;)
>
> Package X example, web2py universal installer
>
> sudo apt-get install universal-web2py
>
> If the web2py package is not installed it gets installed, if mercurial
> is not already installed it gets installed.

easy to do adding dependencies on python-web2py and mercurial to the
universal-web2py package

If a clone of the web2py
> application called “universal installer” does not exist, it is created
> in ${HOME}/web2py/web2py/applications. if web2py is not running it
> starts it and opens default browser to the universal application.
>

mmm, I don't think that should happens without the user intervention.
Don't forget linux is multiuser (and in some schools is used with the
LTSP project, so it's multiuser concurrently).
I think that should be done after the user asks for it, clicking on a
desktop or menu icon.

> The universal application can do almost anything you like then and you
> would easily create additional packages and so forth in this way.
>
> People who want a “server installer” can create a “server installer”
> web2py application and /or debian package that could be made available
> via your universal installer.

my initial idea is providing in /usr/share/doc/python-web2py the
scripts to run web2py at the computer booting and the configuration
files for apache2, httpd-light, index.yaml, etc. with all the needed
documentation to do it manually.
Your idea may be useful to be done with apache, with a apache2-web2py
package, but I don't see how to do it universally for any web server.



>
> Sounds cool!
>

More than cool. It sounds as a need for many people!

Regards.

José L.

[José L.]

On 15 oct, 11:33, Jurgis Pralgauskis <jurgis.pralgaus...@gmail.com>
wrote:
> Maybe You could usehttps://help.launchpad.net/Packaging/SourceBuilds/

>
> if you'd create stable branch on bazar and add packaging recipy likehttps://code.edge.launchpad.net/~mdipierro/web2py/devel/+new-recipe
> fromhttps://code.edge.launchpad.net/~mdipierro/web2py/devel (notice
> code.EDGE.launch...)
>

I prefer to work on the mother distribution, so I've already asked for
a project in alioth.debian.org.

[José L.]

On 15 oct, 13:32, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> You have the idea. Thanks for clearing it towards the others.
>
> My guesses it we need to do both.
> Because Jose goal is general purpose and mine aswell,
> but comes with overkill in the most cases.
>
> In Jose case I would suggest a slight change.
> web2py-core
> web2py-gluon
>
> This has been discusses before, I recall you where in those

> discussions Jose.http://groups.google.com/group/web2py/browse_frm/thread/45ea4327d713b...
>
> http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb52...

>
> There are some other topics, search for turnkeylinux, where this is
> mentioned.
>
> I recall Dimo Barsky was busy with packaging Gluon, but I've been out
> for a while.
> I don't know him, but he might help with this.
>
> It was chaos post again, but I hope this one helps:p.
>
> Mark,

Thanks, but after looking for more info in the links you provided, I
have not been able to find the rationale
for a separate gluon and core packages.

can anybody enlight me?

[Christopher Steel]

IMHO I would not separate anything. A big part of Web2py's magic is
that you do don't need to "install" it. Keeping everything together
insures that upgrades will always work via the web2py web interface
(with a pleasant side effect being that you do not have to repackage
each time Web2py is updated so you get to spend more time doing what
you love ;)

Other matters in no particular order...

If you want "debian" startup scripts you could do it the way you
mentioned, the formal "debian way" or the "web2py" way or some
combination.

You might consider placing them in the web2py/scripts directory (if
Massimo if OK with that). This would make them easy to update (ie. no
(debian) repackaging required) and they would be available to all
Web2py users and developers. I think web2py/scripts/web2py.ubuntu.sh
has a startup example. I the way it is done in the Ubuntu script work
on all other debian systems.

Project X

Project X could be a Debian package containing a "companion" web2py
application. In this case, for Debian users / developers. The idea
being again to free you from the drudgery of repackaging when you (and
optionally others if you so choose) want to update the companion
application.

I mentioned the possibility of using a mercurial clone as this would
give you the freedom to add additional features, customizations and
updates to the companion application, again without needing to update
any debian packages. It has a lot of other very interesting "side
effects" as well including creating a mechanism (via mercurial) that
allows allows other web2py users to contribute to the application, so
if you chose to do so it could become a web2py community application.

By "not" automating companion application updates you give package
users "full control".

Advantages
- Flexibility
- Ability to update the package x companion application without
repackaging.
- Transfer of application maintaining is trivial.
- Others can easily contribute to the package x companion application
by installing package.
- Keeps everyone focused on Web2py.
- Did I mention it is really cool!

Disadvantages
- Requires maintainers for the two debian packages and one web2py
application.
- Too flexible?

Universal Installers and so on.

A setup similar to this opens the door to all the possible things that
one can do with Web2py applications including providing instructions,
links to additional debian packages, apt url installers, chats,
twitter, scripts, server monitoring tools, video instructions,
deployment tools and the list goes up to and including a "Universal
Installer" if one where so inclined. The point being that a Debian
package that including a companion application allows you (or others
if you so choose) to add almost any additional feature at any time
without the need to repackage and redistribute a Debian package,
although this would also be possible if one chose to do so...

Wow , that was really tough to describe in an email!

Keep rockin,

Cheers,

Chris

[mdipierro]

I do not know what the best way and retaining the ability to to hot
upgrades is important. Just to add a piece of information. Jonathan is
working on a re factoring that will allow web2py to be installed in
one folder, keep applications/configurations/logs in another, and run
from a third folder. This should be done soon and will help in this
case.

Massimo

[Mark Breedveld]

Some packager told as that libraries should be in some directory
according too the guidelines. I checked it back then and he was right.
But I don't now how heavy that counts.

It would also be easier to update several instances of web2py since
the most updates will happen there.

But if you say you can pass the guidelines, please do so.
Because it makes it more complex than necessary.

Mark

On Oct 15, 7:06 pm, José L. <jredr...@gmail.com> wrote:
> On 15 oct, 13:32, Mark Breedveld <m.breedv...@solcon.nl> wrote:
>
>
>
> > You have the idea. Thanks for clearing it towards the others.
>
> > My guesses it we need to do both.
> > Because Jose goal is general purpose and mine aswell,
> > but comes with overkill in the most cases.
>
> > In Jose case I would suggest a slight change.
> >web2py-core
> >web2py-gluon
>
> > This has been discusses before, I recall you where in those
> > discussions Jose.http://groups.google.com/group/web2py/browse_frm/thread/45ea4327d713b...
>
> >http://groups.google.com/group/web2py/browse_frm/thread/51b731d9abb52...
>
> > There are some other topics, search for turnkeylinux, where this is
> > mentioned.
>

> > I recall Dimo Barsky was busy withpackagingGluon, but I've been out

[Mark Breedveld]

>> apache2-web2py
Well I originally launched the same plan as you and we also came too
the same conclusion as you. No way too do it, because of the three
reasons I mentioned before.
guidelines, maintainable, etc

So stick to the original plan. Get a simple version of web2py on air.
With documentation.

And if my project succeeds, it will operate as management layer on top
of it. But that's for later and has an other goal.

If that is done, then we could do the apache package.
apache2-wsgi-web2py
apache2-fastgci-web2py
apache2-proxy-web2py
It is possible, but the last time the packaging got stuck on it.

>> A pending question is how to deal with the needed writing permisions.
If you want a per user instance, don't separate the admin. And keep
the ports in mind. You can't run every instance on the same port and
you can't give all user the same instance. Would be a major security
leak.

Suggestion: don't do per user instance. But use the same structure as
apache. One instance, one user/group.
If needed users can manual create there own instance.


Just too keep it going and to keep focus. I have simple question,
because I'm loosing track of the discussion.
Can you package web2py as you have in mind, besides the writing
rights? Which you will discuss later on I guess.

Mark,

[José L.]

On 16 oct, 09:59, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> Some packager told as that libraries should be in some directory
> according too the guidelines. I checked it back then and he was right.
> But I don't now how heavy that counts.
>

It's a must: http://www.debian.org/doc/packaging-manuals/python-policy/

> It would also be easier to update several instances of web2py since
> the most updates will happen there.
>

sure, that's the reason for that policy

> But if you say you can pass the guidelines, please do so.
> Because it makes it more complex than necessary.
>

Not, I haven't said that. You must put the libraries in a directory
(done by python-support in Debian, the directory will depends on the
python version installed, but it will be something like /var/lib/
python-support/python2.5/ ), executables at /usr/bin,other files in /
usr/share/web2py and so on.
But you can do it all with only one package.
I.E. I don't mean it has to be done this way, I just wanted to know if
there are other technical reasons to do it.
It would make sense to have:
python-web2py as a metapackage that depends on python-gluon and python-
web2py-applications, for example. It's only that I don't know if there
are technical or logical reasons to do it. If it has been discussed
and agreed before, it's very possible that's the right way, but I can
not find the thread of discussion for this.

José L.

[José L.]

On 16 oct, 10:54, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> >> apache2-web2py
>
> Well I originally launched the same plan as you and we also came too
> the same conclusion as you. No way too do it, because of the three
> reasons I mentioned before.
> guidelines, maintainable, etc
>
> So stick to the original plan. Get a simple version of web2py on air.
> With documentation.
>
> And if my project succeeds, it will operate as management layer on top
> of it. But that's for later and has an other goal.
>
> If that is done, then we could do the apache package.
> apache2-wsgi-web2py
> apache2-fastgci-web2py
> apache2-proxy-web2py
> It is possible, but the last time the packaging got stuck on it.
>
> >> A pending question is how to deal with the needed writing permisions.
>
> If you want a per user instance, don't separate the admin.

I want to separate the admin because it's something the user should
not touch, and should be upgraded everytime the package is upgraded.
Moving the admin application to the userland won't allow upgrading it
with new versions of the package.

But... the user has to run the admin project, so it needs to write
sessions, logs, etc. for this project.

And keep
> the ports in mind. You can't run every instance on the same port and
> you can't give all user the same instance. Would be a major security
> leak.
>
> Suggestion: don't do per user instance. But use the same structure as
> apache. One instance, one user/group.
> If needed users can manual create there own instance.
>

I fully agree with you... but there's a big difference with apache if
you're not running apache. Starting the rocket server is done by any
user without special permssions (tcp port over 1000). So we have a
dillema: adding apache as a dependency and running it all under apache
umbrella would make things easier. At the same time this breaks the
easy of use of web2py when rocketserver is used and would force the
users to be in a special group to be able of program with web2py.

> Just too keep it going and to keep focus. I have simple question,
> because I'm loosing track of the discussion.
> Can you package web2py as you have in mind, besides the writing
> rights? Which you will discuss later on I guess.

I'll try. Anyway, I've requested the creation of a packaging group in
alioth.debian.org. As soon as it is created by the admins I'll tell it
here, so anybody can join to help.

Regards
José L.


>
> Mark,

[LightDot]

I have written an internal Fedora RPM for web2py a while ago and tried
to follow Fedora's packaging guidelines. I'm a RHEL/CentOS sysadmin
and take care of quite a few hosting servers, my main objective was to
easily use it on our RHEL/CentOS servers with Cherokee.

I don't want to "steal" the Debian related thread, but I'd like to
comment and discuss some of the proposed changes since they are
relevant to any OS packages, not only Debian.


I found the following difficulties/questions when I created our RPMs:

- web2py has a very rapid release cycle. That makes it difficult to
get it in EPEL repository properly (for RHEL and CentOS), perhaps
RPMFusion would be a better choice. If it gets in Fedora directly,
CentOS and RHEL admins won't have optimal access to the package
- I guess one should take a "stable" release and package it, than
follow the changelog and make a new package every month or so. A new
release every couple of days isn't going to work with distribution
repositories, since packages go trough a prolonged testing phase.
Backwards compatibility helps (great!) but still, one release per
month is probably the best one can hope for

- it must be possible to use a separate applications folder (in a sane
manner, perhaps as ~/.web2py/applications in a user home folder and
other places)
- several locations of applications folder should coexist and get used
by different end users, depending on how one starts web2py
- these application folders belong to users, RPM doesn't touch them

- does admin count as a regular application? How to update it? Should
there be a single admin app per physical server? How to protect it and
how to separate users? How to adjust this for different web servers?
- how to disable updating and version checking from a web interface?
It shouldn't happen when using an RPM (or .deb). I guess one could
remove this functionality with a patch
- all relevant web2py .py files should be compiled as .pyc at
packaging stage since end users won't be able to achieve this. It also
makes RPM upgrade and removal stages cleaner
- RPM (or .deb, etc.) should not interfere with hosting customers who
upload their own complete web2py
- should there be a startup script that starts web2py with internal
server or...? This isn't going to get used in an enterprise
environment
- how to deal with the choice of Apache, Cherokee, etc.

I also don't see why gluon and other core files should be separated
one from another, perhaps I'm missing something. Just the
applications, documentation and perhaps the contributed scripts must
be separated from the core/gluon. And what should be done with the
admin app?

I packaged web2py as:
web2py-core
we2py-admin
web2py-examples

The applications folder issues remained. Admin app was enabled for
server administrator only, overwritten with upgrades. Example apps
were overwritten with upgrades. The RPMs were closely linked with
Cherokee but that was just for our internal use. I also made a
separate README, provided sample scripts (conf, xml, etc.) for Apache
mod_wsgi and Cherokee with uwsgi and let the admin set it up with a
web server of his choice.

I'd be glad to hear any comments and could maintain the RPM part of
packaging if the issues get ironed out. Or I can just provide my .spec
files to give a head start to a future RPM maintainer, it really
doesn't matter.

All this being said, there is still a fundamental question of
packaging rationale. Should web2py get packaged at all? Or should it
remain in userland alltogether, similar to CakePHP and various other
frameworks of any kind.

Various other web application packages such as phpmyadmin, etc. do get
packaged, so...

In any case, I'm going to keep maintaining the RPMs for our internal
use and I'd appreciate any additional comments.

Kind regards to all.

[mdipierro]

Thanks this is a helpful comment. I will ty to answer some questions
although I do not have an answer.

On Oct 16, 8:40 am, LightDot <light...@gmail.com> wrote:
> I have written an internal Fedora RPM for web2py a while ago and tried
> to follow Fedora's packaging guidelines. I'm a RHEL/CentOS sysadmin
> and take care of quite a few hosting servers, my main objective was to
> easily use it on our RHEL/CentOS servers with Cherokee.
>
> I don't want to "steal" the Debian related thread, but I'd like to
> comment and discuss some of the proposed changes since they are
> relevant to any OS packages, not only Debian.
>
> I found the following difficulties/questions when I created our RPMs:
>
> - web2py has a very rapid release cycle. That makes it difficult to
> get it in EPEL repository properly (for RHEL and CentOS), perhaps
> RPMFusion would be a better choice. If it gets in Fedora directly,
> CentOS and RHEL admins won't have optimal access to the package
> - I guess one should take a "stable" release and package it, than
> follow the changelog and make a new package every month or so. A new
> release every couple of days isn't going to work with distribution
> repositories, since packages go trough a prolonged testing phase.
> Backwards compatibility helps (great!) but still, one release per
> month is probably the best one can hope for

This means these users will be always behind. :-(

> - it must be possible to use a separate applications folder (in a sane
> manner, perhaps as ~/.web2py/applications in a user home folder and
> other places)

We are working on it.

> - several locations of applications folder should coexist and get used
> by different end users, depending on how one starts web2py

This will be possible when previous point is addressed. Soon.

> - these application folders belong to users, RPM doesn't touch them
>
> - does admin count as a regular application? How to update it? Should
> there be a single admin app per physical server? How to protect it and
> how to separate users? How to adjust this for different web servers?

Do not know. that is the problem. Web2py is designed to give a lot of
control to users. Packaging one set of *.py files takes away such
control.

> - how to disable updating and version checking from a web interface?
> It shouldn't happen when using an RPM (or .deb). I guess one could
> remove this functionality with a patch

Why disable the check? Because upgrade would not work (true)?

> - all relevant web2py .py files should be compiled as .pyc at
> packaging stage since end users won't be able to achieve this. It also
> makes RPM upgrade and removal stages cleaner
> - RPM (or .deb, etc.) should not interfere with hosting customers who
> upload their own complete web2py

This should not be a problem.

[José L.]

On 16 oct, 15:40, LightDot <light...@gmail.com> wrote:
> I have written an internal Fedora RPM for web2py a while ago and tried
> to follow Fedora's packaging guidelines. I'm a RHEL/CentOS sysadmin
> and take care of quite a few hosting servers, my main objective was to
> easily use it on our RHEL/CentOS servers with Cherokee.
>

Great

> I don't want to "steal" the Debian related thread, but I'd like to
> comment and discuss some of the proposed changes since they are
> relevant to any OS packages, not only Debian.
>

Sure

> I found the following difficulties/questions when I created our RPMs:
>
> - web2py has a very rapid release cycle. That makes it difficult to
> get it in EPEL repository properly (for RHEL and CentOS), perhaps
> RPMFusion would be a better choice. If it gets in Fedora directly,
> CentOS and RHEL admins won't have optimal access to the package
> - I guess one should take a "stable" release and package it, than
> follow the changelog and make a new package every month or so. A new
> release every couple of days isn't going to work with distribution
> repositories, since packages go trough a prolonged testing phase.
> Backwards compatibility helps (great!) but still, one release per
> month is probably the best one can hope for

I totally agree

>
> - it must be possible to use a separate applications folder (in a sane
> manner, perhaps as ~/.web2py/applications in a user home folder and
> other places)
> - several locations of applications folder should coexist and get used
> by different end users, depending on how one starts web2py

We depend on Massimo and other web2py developers to achieve this.
Massimo said he's working on it. So we should think this is going to
happen.

> - these application folders belong to users, RPM doesn't touch them
>

Of course

> - does admin count as a regular application?

I think it does


- How to update it?

With its package

> Should
> there be a single admin app per physical server?

I think so

>How to protect it and
> how to separate users?

One option would be adding a new system group (or using www-data) and
all users in that group will have the same access.
Another option would be symlinking the only admin application to the
home directory of the user, so any user would be able to run it in his
own environment.

> How to adjust this for different web servers?

In my opinion, we have to options: not do it, and giving examples and
documentation on how to do it. Or doing it with different packages for
every server.

> - how to disable updating and version checking from a web interface?
> It shouldn't happen when using an RPM (or .deb). I guess one could
> remove this functionality with a patch

Yes

> - all relevant web2py .py files should be compiled as .pyc at
> packaging stage since end users won't be able to achieve this. It also
> makes RPM upgrade and removal stages cleaner

Not in Debian packages. The package should contain only the .py files.
In Debian and its derivatives, when a python package in installed, it
will compile the .py files with the user Python version, and place
the .pyc files in different directories depending on the user python
version.

> - RPM (or .deb, etc.) should not interfere with hosting customers who
> upload their own complete web2py

Of course, but I don't think this is a problem if we don't set it up
with a web server.

> - should there be a startup script that starts web2py with internal
> server or...? This isn't going to get used in an enterprise
> environment

In the raw version (without web server setup) I think it shouldn't. it
should be started manually by the user.

> - how to deal with the choice of Apache, Cherokee, etc.
>

Not doing it at all, or doing it with different packages.

> I also don't see why gluon and other core files should be separated
> one from another, perhaps I'm missing something. Just the
> applications, documentation and perhaps the contributed scripts must
> be separated from the core/gluon. And what should be done with the
> admin app?
>
> I packaged web2py as:
> web2py-core
> we2py-admin
> web2py-examples
>

I think this is a very smart division. I'd only add a python-web2py
metapackage with dependencies on all of the above. So if the user
installs python-web2py, all the packages are automagically installed.

> The applications folder issues remained. Admin app was enabled for
> server administrator only, overwritten with upgrades. Example apps
> were overwritten with upgrades. The RPMs were closely linked with
> Cherokee but that was just for our internal use. I also made a
> separate README, provided sample scripts (conf, xml, etc.) for Apache
> mod_wsgi and Cherokee with uwsgi and let the admin set it up with a
> web server of his choice.
>
> I'd be glad to hear any comments and could maintain the RPM part of
> packaging if the issues get ironed out. Or I can just provide my .spec
> files to give a head start to a future RPM maintainer, it really
> doesn't matter.

I'd like to read your .spec file. I'm sure it can help in the Debian
packaging as you've already worked in the same issues we've been
discussing here.

>
> All this being said, there is still a fundamental question of
> packaging rationale. Should web2py get packaged at all? Or should it
> remain in userland alltogether, similar to CakePHP and various other
> frameworks of any kind.
>
> Various other web application packages such as phpmyadmin, etc. do get
> packaged, so...
>

I think it should. Not only thinking in users wanting to use web2py,
but in applications developed using web2py. In the future there will
be applications made with web2py that we'll want to be in main Linux
distributions. If we want those applications being in the
repositories, a previous step is having web2py. In terms of Debian
packaging we have to study deeply all the dependencies. Not only
technical depedendencies but also legal ones. web2py includes several
javascript files made by other people, and I want it to pass the legal
exam in Debian.

> In any case, I'm going to keep maintaining the RPMs for our internal
> use and I'd appreciate any additional comments.
>

I thank you your comments, and I hope you can help in the Debian
packaging too, as most problems (if not they all) are common to any
distribution packaging. The final way of compiling the package
differs, but I can't recall of any other difference.

Regards.
José L.


> Kind regards to all.

[José L.]

The debian packaging group is online:
http://alioth.debian.org/projects/pkg-web2py/

Please, join the group if you want to collaborate/help/test the
packaging.

I'll wait some days before beginning to upload the first files.

Also, all the packaging talk can be done in the group, instead of
flooding this group of packaging technical details that most people
don't care.

Regards.
José L.