web2py breakage for compiled apps

[Niphlod]

see https://groups.google.com/d/msg/web2py/8fmz3sRmF98/HRvk_ZimAAAJ

why has this https://github.com/web2py/web2py/pull/1194 been merged ? 

merging without the corresponding regression test made 2.13.4 break.

I'd suggest to reasses on compiled apps (don't recall right now why we switched from "_" to "." as a separator), but right now views are compiled with "_", controllers and models with "."  ... wouldn't be better to use "." in views too (granted that the switch from "_" to "." was done for a valid reason) ?

Also, I don't get why compileapp still seeks for both formats: I'd get an implementation that slows down execution for the "old" format, but the current slows it down for everybody!!!

[Niphlod]

logged an issue for it, just to get it tracked. https://github.com/web2py/web2py/issues/1310

once fixed, this is one of the areas of main concern for people using web2py for compiled apps (and "using" web2py as a framework to ship those as a framework that promises to never break their app)

[Anthony]

I wonder if backward compatibility should apply to compiled files. Perhaps the expectation should be if you are upgrading the framework, then you should re-compile the app.

Note, the logic in question is intended to allow creating compiled apps where some subset of the views are not compiled (using Python expressions in "include" and "extend" directives prevents compiling of such views). This capability would be much more helpful if the admin app actually allowed apps with non-compileable views to be compiled (it simply throws an error now). At one point in the distant past I had sent a patch adding another compile option in admin for this purpose (it allowed non-compileable views without throwing an error, and reported the views that weren't compiled), but it was never applied. It is attached.

Anthony

[Niphlod]

IMHO backward still stands for a single occasion: you compiled AND shipped an app to "vendorize it" rather than for speed purposes only... and you expect your app to work also in a latter web2py release. 

That being said, there are two main topics:

- why controllers and models use a "." and views use a "_" ? even if there's no real reason (I'm not saying there isn't, just that I don't recall why at some point we switched) normalization would help keeping things in check

- given backward compatibility is needed, in this (and other occurrences), core code should check for the "latest way of doing things" and return early ELSE do all the the further step(s) more to ensure backward compatibility at the expense of efficiency and speed. Warnings on CHANGELOG should warn users about relevant state of things.

[Anthony]

On Wednesday, April 27, 2016 at 4:54:12 PM UTC-4, Niphlod wrote:

IMHO backward still stands for a single occasion: you compiled AND shipped an app to "vendorize it" rather than for speed purposes only... and you expect your app to work also in a latter web2py release.

We typically talk about backward compatibility applying to the public API. I'm not saying we absolutely shouldn't worry about backward compatibility regarding compiled code, but I'm not sure we have promised it or whether it is worth complicating the codebase to preserve it given that re-compiling is a quick and completely automated step that requires no code changes.

And I wonder how common it is for someone to have only the compiled version of an app but also be responsible for (and interested in) doing their own upgrades of the framework. If someone has been given a standalone binary and they want to upgrade, they'll need to be given a new standalone binary anyway, and whoever creates that can simply re-compile the app.

 

That being said, there are two main topics:

- why controllers and models use a "." and views use a "_" ? even if there's no real reason (I'm not saying there isn't, just that I don't recall why at some point we switched) normalization would help keeping things in check

- given backward compatibility is needed, in this (and other occurrences), core code should check for the "latest way of doing things" and return early ELSE do all the the further step(s) more to ensure backward compatibility at the expense of efficiency and speed. Warnings on CHANGELOG should warn users about relevant state of things.

Agreed. Not sure why the change was made, and if we must deal with backward compatibility, make those checks later.

Anthony

[Leonel Câmara]

Frankly I don't care about backwards compatibility with compiled applications at all. If you distribute only the compiled application you should have the burden of making sure it works with new releases and release a new version when it doesn't. And I also think it makes sense to name the compiled views exactly the same way you name controllers and models so I agree with the change.  

  

In fact I would like us to have a mechanism of regularly breaking backwards compatibility even at the source level maybe by having a versioning scheme like ubuntu, regular releases, and LTS releases which only get bugfixes. Then we would do migration guides for people when we released a new LTS which would be a combination of the migration guides for the releases in between. I think this is better than just making a web3py as that will alienate users, we should just keep evolving web2py.  

[Niphlod]

ok, 3 people voting for "." anywhere and not bothering for backward compatibility. mdipierro, thoughts ?

[Paolo Valleri]

Thinking about crud, I agree about breaking backward compatibility in order to deprecate former modules (and after a while removing it from web2py build). Ok for dropping py26. 

However, the idea of changing things here and there will complicate a lot the upgrade of all applications.

 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.