Hi Dimo,
I agree on the fact that there more roles.
And I want to make a clear separation in the repo.
Web2py applications for production use are put in the usr folder.
And copied and protected by a startup script.
For example you could take the write right from /controllers /models /
views
And store static and upload under var or or the user location
mentioned in a email before.
Web2py applications for development are put in the user location or /
var
Together with the application uploaded from web2py own application
mechanism
Those applications may never ever overwrite each other (I agree with
you on that too)
It is the most advance solution till now,
But it's quite complex.
Because of various way to run web2py.
And it isn't very concrete at the moment,
But it's a start.
Regards Mark,
-----Oorspronkelijk bericht-----
Van: web2py@googlegroups.com [mailto:web...@googlegroups.com] Namens
Dima Barsky
Verzonden: dinsdag 23 maart 2010 11:26
Aan: web2py@googlegroups.com
Onderwerp: Re: [web2py] Re: Debian / Ubuntu packager needed!
On Tue, 23 Mar 2010 02:06:16 -0700 (PDT), Mark Breedveld
<m.breedv...@solcon.nl> wrote:
> I'll see both problems and another solution to work around this.
> We could install web2py into /usr/ directories with apt.
>
> Then create a startup script that makes a copy of web2py and the
> web2py applications that are installed trough apt to the /var folder.
> A so called runtime version of web2py.
This will work, but why would you want to do this? It will create more
problems than it solves.
Imagine the following scenario: you develop a web2py application
called
XYZ, which is packaged and distributed via Debian. A user installs XYZ
version 1.2.3 and starts playing with the runtime version in /var,
adding
new views and controllers and modifying the existing ones. Some time
later
you release XYZ 1.3.0 which gets installed on the user's computer via
an
automatic update. Now there are two version of XYZ on that computer -
the
mainstream 1.3.0 in /usr and user-modified 1.2.3 in /var. The changes
that
you made in 1.3.0 are incompatible with the user's changes, so there
is no
easy way to merge them together. The startup script can not just
override
the user's changes and install 1.3.0 in /var, that would be cruel.
Let's
assume it leaves 1.2.3 in /var intact. Now the user notices a bug in
your
application and decides to submit a bug report using one of the
standard
bug-reporting tools in Debian. The tool looks at the packaging
database and
reports that the user has XYZ 1.3.0 installed. Imagine your confusion
when
you receive this bug report, you thought you had fixed this problem,
but
it's still there. It's a nightmare, I would not want to maintain such
an
application.
Let's admit that there are different roles: developers develop
applications, users use them. When a user wants to become a developer
he
can install the application in his home dir and start working on it.
There
is another class of users who don't have any intention of modifying
the
application. They just want to use it, they want stability and
predictability, and the packaging system gives them that.
Regards,
Dima.
--
You received this message because you are subscribed to the Google
Groups "web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to web2py
+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
On Mar 23, 11:25 am, Dima Barsky <d...@debian.org> wrote:
> On Tue, 23 Mar 2010 02:06:16 -0700 (PDT), Mark Breedveld
>
> <m.breedv...@solcon.nl> wrote:
> > I'll see both problems and another solution to work around this.
> > We could install web2py into /usr/ directories with apt.
>
> > Then create a startup script that makes a copy of web2py and the
> > web2py applications that are installed trough apt to the /var folder.
> > A so called runtime version of web2py.
>
> This will work, but why would you want to do this? It will create more
> problems than it solves.
>
> Imagine the following scenario: you develop a web2py application called
> XYZ, which is packaged and distributed viaDebian. A user installs XYZ
> version 1.2.3 and starts playing with the runtime version in /var, adding
> new views and controllers and modifying the existing ones. Some time later
> you release XYZ 1.3.0 which gets installed on the user's computer via an
> automatic update. Now there are two version of XYZ on that computer - the
> mainstream 1.3.0 in /usr and user-modified 1.2.3 in /var. The changes that
> you made in 1.3.0 are incompatible with the user's changes, so there is no
> easy way to merge them together. The startup script can not just override
> the user's changes and install 1.3.0 in /var, that would be cruel. Let's
> assume it leaves 1.2.3 in /var intact. Now the user notices a bug in your
> application and decides to submit a bug report using one of the standard
> bug-reporting tools inDebian. The tool looks at the packaging database and
> reports that the user has XYZ 1.3.0 installed. Imagine your confusion when
> you receive this bug report, you thought you had fixed this problem, but
> it's still there. It's a nightmare, I would not want to maintain such an
> application.
>
> Let's admit that there are different roles: developers develop
> applications, users use them. When a user wants to become a developer he
> can install the application in his home dir and start working on it. There
> is another class of users who don't have any intention of modifying the
> application. They just want to use it, they want stability and
> predictability, and the packaging system gives them that.
>
> Regards,
> Dima.
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
