> New features not documented in Book (2nd edition)
>
> 1.75.2
> - no more cron with -S option
> - ability to override/upgrade and app
overwrite
>
> 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.
> 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.
>
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
On Mar 3, 1:34 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
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
> you can already trash an application
We want to trash the application, but not the application state (database, etc).
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
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