[web2py] Re: Packaging web2py for Debian
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.
[web2py] Re: Packaging web2py for Debian
On 16 oct, 15:40, LightDot 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 l
[web2py] Re: Packaging web2py for Debian
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 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. > - 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.
[web2py] Re: Packaging web2py for Debian
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.
[web2py] Re: Packaging web2py for Debian
On 16 oct, 10:54, Mark Breedveld 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,
[web2py] Re: Packaging web2py for Debian
On 16 oct, 09:59, Mark Breedveld 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.
[web2py] Re: Packaging web2py for Debian
>> 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,
[web2py] Re: Packaging web2py for Debian
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. wrote: > On 15 oct, 13:32, Mark Breedveld 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 > > 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?
[web2py] Re: Packaging web2py for Debian
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 On Oct 15, 6:04 pm, Christopher Steel wrote: > 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 > > On Oct 15, 1:06 pm, José L. wrote: > > > On 15 oct, 13:32, Mark Breedveld 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? > >
[web2py] Re: Packaging web2py for Debian
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 On Oct 15, 1:06 pm, José L. wrote: > On 15 oct, 13:32, Mark Breedveld 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?
[web2py] Re: Packaging web2py for Debian
On 15 oct, 13:32, Mark Breedveld 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?
[web2py] Re: Packaging web2py for Debian
On 15 oct, 11:33, Jurgis Pralgauskis 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.
[web2py] Re: Packaging web2py for Debian
On 14 oct, 23:51, Christopher Steel 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.
[web2py] Re: Packaging web2py for Debian
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,
On 14 okt, 23:51, Christopher Steel 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
>
> 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 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. wrote:
>
> > > On 14 oct, 17:24, Mark Breedveld 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
[web2py] Re: Packaging web2py for Debian
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 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 > 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. : > > > > 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. > > > > 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. > >
[web2py] Re: Packaging web2py for Debian
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 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. wrote:
>
> > On 14 oct, 17:24, Mark Breedveld 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 be
[web2py] Re: Packaging web2py for Debian
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. wrote: > On 14 oct, 17:24, Mark Breedveld 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.
[web2py] Re: Packaging web2py for Debian
On 14 oct, 17:24, Mark Breedveld 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.
[web2py] Re: Packaging web2py for Debian
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, On 14 okt, 08:38, José L. wrote: > On 14 oct, 02:36, Mark Breedveld 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.
[web2py] Re: Packaging web2py for Debian
On 14 oct, 02:36, Mark Breedveld 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.
[web2py] Re: Packaging web2py for Debian
On 13 oct, 23:18, Tim Michelsen 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. > > You can have automatic daily builds of a source tree import to your > PPA:https://help.launchpad.net/Packaging/SourceBuilds/Recipes 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.
[web2py] Re: Packaging web2py for Debian
On 13 oct, 23:17, Richard 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.
[web2py] Re: Packaging web2py for Debian
On 13 oct, 22:29, mdipierro 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 > 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. : > > > > 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. > > > > 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.
[web2py] Re: Packaging web2py for Debian
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) On 14 okt, 01:12, "Martin.Mulone" wrote: > On 13 oct, 18:17, Richard 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.
[web2py] Re: Packaging web2py for Debian
On 13 oct, 18:17, Richard 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.
Re: [web2py] Re: Packaging web2py for Debian
+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 : > 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 wrote: >> I remember talk about ability to upgrade through admin - is that >> practical? >> >> On Oct 14, 7:29 am, mdipierro 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 >> > 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. : >> >> > > > 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. >> >> > > > 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. >> >>
[web2py] Re: Packaging web2py for Debian
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 wrote: > I remember talk about ability to upgrade through admin - is that > practical? > > On Oct 14, 7:29 am, mdipierro 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 > > 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. : > > > > > 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. > > > > > 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. > >
[web2py] Re: Packaging web2py for Debian
> 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
[web2py] Re: Packaging web2py for Debian
I remember talk about ability to upgrade through admin - is that practical? On Oct 14, 7:29 am, mdipierro 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 > 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. : > > > > 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. > > > > 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. > >
[web2py] Re: Packaging web2py for Debian
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 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. : > > > 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. > > > 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. > >
[web2py] Re: Packaging web2py for Debian
On 13 oct, 21:00, mdipierro 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
[web2py] Re: Packaging web2py for Debian
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. 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. > > 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.
