web2py upgrade to 2.9.12 broken

[Niphlod]

FYI https://groups.google.com/d/msg/web2py/eXIt4HaHF44/5_lnoV9dSusJ

I think that before the new release this should be addressed so we can avoid newbies/seasoned users to be scared of updating web2py.
We - developers - like to run trunk without issues, and we fly from version to version with incremental-little-updates with flying colors......... we also kill ourselves and have nightmares all night long in the spirit of backward compatibility ...
but for users that do care about upgrading to the next "stable-thingy" (yep, I actually heard myself calling that way a new release :-P) web2py is perceived as a broken-thingy to upgrade to.

[Paolo Valleri]

Hi,

the current upgrade fails because it doesn't remove 'old' files. I've a 'dirty solution' in mind: split the current upgrade process into two phases.

-1st update process will download a zip (http://web2py.com/examples/static/web2py_src.zip) containing ONLY an updated version of gluon/admin.py. 

-2nd update process will download the whole new web2py by using a new(and updated) gluon/admin.py (by using a different link).

I don't know if this approach can work or not.

 Paolo

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Niphlod]

The whole idea of promoting a safe upgrade fails badly for two distinct sets of issues:
a) web2py upgrade per se
b) applications artifacts


a) web2py couldn't/can't/won't be upgraded in place successfully EVEN if old files are in the same path of new ones because there can be an apache,wsgi,python etc etc etc process running it with no permissions at all to update/delete/create files outside applications/*
Even with the most easy environment for an upgrade (a process running web2py.py with all the needed permissions), at the most-bare-level of any "upgrade-logic", given that unzip(src, dst) is not atomical it doesn't close the deal

b) just complicates over upon the previous "sand-castle": in-between releases (such as 2.9.11 to 2.9.12) due to changes in code, apps need to be cleaned properly in the exact time that passes from "old" env processing the last request and before the "new updated" one takes in charge the first request coming in

[Massimo DiPierro]

So.what do you suggest?  Deliver an upgrade script?

[Leonel Câmara]

I think we could overcome these problems for the easy scenario.

- How about, compile all applications and files in gluon to pyc.

- Perform the upgrade.

- Disable all applications

- Remove all sessions/cache/whatever.

- Delete all pyc files and compiled applications.

- Done?

[Michele Comitini]

And if someone has a compiled only application?

--

[Leonel Câmara]

Well we don't really need to compile the applications, I don't know why I  included that step anyway, all that matters are the pyc files in gluon.

[Niphlod]

@massimo: at the very least mark the upgrade button as "something can break if you press this" . Right now it's perceived at "it will always work" but there are tons of cases (let alone the current 2.9.11-->2.9.12 "I'll break by default" behaviour) that build up to a lot of users (i.e. those are not corner-cases).
Again, we can provide scripts but there are too much variables in place ... I fear we won't be able to code something that works everywhere.

this and this are clearly jokes around a very restricted part of the whole use-case scenario.

@leonel: could theoretically work for source, but again it's not atomical and not a solution for binaries or web2py deployed behind a webserver with no permissions.

[Massimo DiPierro]

If I am not mistaken only upgrading the source app creates problems, not the binary apps. They contain a zip file that gets correctly overwritten.

So we could disable the auto-upgrade of source apps since they should know better.

I can post a twit about this and it should appear on the users’s admin page. Will they read it?

[Leonel Câmara]

Well we could make it atomic if we make the upgrade gluon only. gluon could be a symlink or a junction point in windows, so all upgrade would do would be to download gluon_2_9_12 unzip it and change the gluon symlink to point to gluon_2_9_12 instead of pointing to gluon_2_9_11.  

  

It will obviously never be possible to upgrade automatically if the process doesn't have permissions to do it, but the same could be said for code editing in admin and we still have that feature. This could be checked before performing the upgrade.

[Niphlod]

On Friday, January 23, 2015 at 11:36:27 AM UTC+1, Leonel Câmara wrote:

Well we could make it atomic if we make the upgrade gluon only. gluon could be a symlink or a junction point in windows, so all upgrade would do would be to download gluon_2_9_12 unzip it and change the gluon symlink to point to gluon_2_9_12 instead of pointing to gluon_2_9_11.  

  

It will obviously never be possible to upgrade automatically if the process doesn't have permissions to do it, but the same could be said for code editing in admin and we still have that feature. This could be checked before performing the upgrade.

r/w permissions inside applications/* is usually allowed, or a bunch of things start to break real soon (disk cache, sessions in files, languages, static minification and inlining, maybe something else). gluon on the other end may not.