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
On Oct 14, 3:36 pm, Mark Breedveld <m.breedv...@solcon.nl> wrote:
> 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,
>
> On 14 okt, 20:03, José L. <jredr...@gmail.com> wrote:
>
> > 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.
>
>
