Re: [web2py] New features not documented in Book (2 ed)

4 views
Skip to first unread message

Jonathan Lundell

unread,
Feb 16, 2010, 11:21:44 AM2/16/10
to web...@googlegroups.com
On Feb 16, 2010, at 7:16 AM, DenesL wrote:

> New features not documented in Book (2nd edition)
>
> 1.75.2
> - no more cron with -S option
> - ability to override/upgrade and app

overwrite

DenesL

unread,
Feb 16, 2010, 11:32:19 AM2/16/10
to web2py-users

Thanks (it is copy/paste of the original).
Do you know of any docs on usage?.

Jonathan Lundell

unread,
Feb 16, 2010, 12:08:17 PM2/16/10
to web...@googlegroups.com
On Feb 16, 2010, at 8:32 AM, DenesL wrote:

>
> Thanks (it is copy/paste of the original).
> Do you know of any docs on usage?.

On the admin app's app-installation page, there's a checkbox to enable overwriting of an uploaded app. If not checked, the behavior is the same as before: an attempt to install an app with the same name as an installed app fails. In the overwrite case, the new app simply gets untarred over the old app.

Dragonfyre13

unread,
Mar 3, 2010, 12:48:57 PM3/3/10
to web2py-users
If it's untarred over the top of the old one, any files that are not
in the new tar file will be left there. Since an app is supposed to
kind of be self contained, shouldn't it remove the old app, and then
untar to the directory?

Jonathan Lundell

unread,
Mar 3, 2010, 1:18:11 PM3/3/10
to web...@googlegroups.com
On Mar 3, 2010, at 9:48 AM, Dragonfyre13 wrote:

> If it's untarred over the top of the old one, any files that are not
> in the new tar file will be left there. Since an app is supposed to
> kind of be self contained, shouldn't it remove the old app, and then
> untar to the directory?

Probably, though I'm not sure that it's always obvious which files to delete.

For the app I'm working on, it'd be everything in (controllers,models,modules,private,views,static). I think. But is that always the right list?

>
> On Feb 16, 11:08 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>> On Feb 16, 2010, at 8:32 AM, DenesL wrote:
>>
>>
>>
>>> Thanks (it is copy/paste of the original).
>>> Do you know of any docs on usage?.
>>
>> On the admin app's app-installation page, there's a checkbox to enable overwriting of an uploaded app. If not checked, the behavior is the same as before: an attempt to install an app with the same name as an installed app fails. In the overwrite case, the new app simply gets untarred over the old app.
>>
>>> On Feb 16, 11:21 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>>>> On Feb 16, 2010, at 7:16 AM, DenesL wrote:
>>
>>>>> New features not documented in Book (2nd edition)
>>
>>>>> 1.75.2
>>>>> - no more cron with -S option
>>>>> - ability to override/upgrade and app
>>
>>>> overwrite
>

> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
>


Yarko Tymciurak

unread,
Mar 3, 2010, 2:34:03 PM3/3/10
to web2py-users
On Mar 3, 11:48 am, Dragonfyre13 <dragonfyr...@gmail.com> wrote:
> If it's untarred over the top of the old one, any files that are not
> in the new tar file will be left there. Since an app is supposed to
> kind of be self contained, shouldn't it remove the old app, and then
> untar to the directory?

A trivially simple way to handle this would be to have the concept of
an application "trash can", where
a current app would be moved to "trash", and a new one installed.

Another way would be to literally have app-area per-application
repositories (hg), and literall just "pull" the new app (including any
file deletions) - but this would mean the tar / w2p file format
giving way to /letting mercurial manage updates in these circumstances
(which would probably not be bad).

- Yarko

mdipierro

unread,
Mar 3, 2010, 3:22:59 PM3/3/10
to web2py-users
you can already trash an application

On Mar 3, 1:34 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:

Yarko Tymciurak

unread,
Mar 3, 2010, 4:09:56 PM3/3/10
to web2py-users
On Mar 3, 2:22 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> you can already trash an application

How? (From the admin interface? - I don't see a trash-can to "undo"
this from...)

In any case, the discussion was about "overrite installed app"
behavior, and the problem with files no longer used, and managing
that...

One exploratory suggestion I made: Recoverable trash can (and perhaps
replacing "overwrite existing app" with "replace existing app")

Another: have local hg manage it (and I know you've already said you
don't like this, because it means "one more distributon dependency" -
but with discussion, there might be a non-trivial path to this, e.g.:
declare local SCM, and admin plugins to handle hg, git, or svn, for
example.... as messy as that is, it is _an approach_ to a solution to
this problem).

Anyway, this (I thought) was exploratory discussion....

- Yarko

Jonathan Lundell

unread,
Mar 3, 2010, 4:35:50 PM3/3/10
to web...@googlegroups.com
On Mar 3, 2010, at 12:22 PM, mdipierro wrote:

> you can already trash an application

We want to trash the application, but not the application state (database, etc).

Christopher Steel

unread,
Mar 5, 2010, 1:29:24 AM3/5/10
to web2py-users
How about this,

Create a script to rename the app as follows

Myappname-hide

Now the app will "disappear" in the web2py interface.

The app (and everything in the app directory) remain, but Will no
longer show up in web2py because the folder name contains a "-"
hyphen.

You need to test, but might do the trick easily. To "undelete /
recycle" you remove the hyphen. Will that work for you?

Chris

Yarko Tymciurak

unread,
Mar 5, 2010, 1:32:39 PM3/5/10
to web2py-users

On Mar 5, 12:29 am, Christopher Steel <chris.st...@gmail.com> wrote:
> How about this,
>
> Create a script to rename the app as follows
>
> Myappname-hide

That is too "clever" - if you're going to do this, be explicit: move
the application to some "trash-can" folder.

In any case, this does not address the point Jonothan brought up -
about wanting to preserve application state (does everyone agree this
is valid?).

I think this is saying the best way to do this is use existing
technolodgy, and use a versioning system.
Massimo said he didn't want to include / depend on this with a distro,
so perhaps optional functionality if you have it sepcified.

I would pick one from a "crowd" - I think an important split is those
that versoin directories, and those that version files.
Directories versioned: SVN & bazaar;
Files Versioned: mercurial & git;

If there were plugins (gluon level?) for this, are there any things
that would get in the way? I.e., if you have your test environment
checked out from the mercurial repository, I think you cannot have
applications have their own mercurial (is that correct?).

... just thinking out loud.

- Yarko

Reply all
Reply to author
Forward
0 new messages