The Tethys Platform 4 release candidate is out!

[swainn]

This is for all you early adopters: the release candidate for Tethys Platform 4 is out!

You can install it alongside your Tethys 3 environment to test as follows:

conda create -n tethys4 -c tethysplatform/label/dev -c conda-forge tethys-platform
conda activate tethys4

Then complete the installation starting with step 3: Tethys Platform: Getting Started

The documentation for the release candidate can be found here:

http://docs.tethysplatform.org/en/latest/

We recommend you start with What's New and Migrate Apps.

Post feedback on the release candidate on this discussion or post an issue to report bugs.

--
Tethys Platform Steering Committee

[rileyhales]

I saw that there is now a deprecation warning for using url maps and that support will be dropped in tethys 4.1 in favor of using decorators. I don't think that should happen. Using url maps should remain an acceptable way to provide routes. I think this dropping them is a bad idea for these reasons:

1. Dropping support for a feature without a major version change introduces breaking changes and is inherently non-backwards compatible. It should not be dropped until version 5.0. Otherwise version 4.1 will not be compatible with version 4.0 and all conventions for checking versioning will fail. For instance, the tethys app store will need to become ultra specific about what version of tethys an app can run on.
2. Decorators should not become the only option because the core Django project still instructs you to use a urls.py file. Some python frameworks give you the option of using decorators but this is a Django based software. I don't have a problem with including the ability to use decorators in addition but not in place of the core Django way. Refer to the Django tutorial where it instructs you to list your url routes in urls.py. https://docs.djangoproject.com/en/4.1/intro/tutorial01/#write-your-first-view.
3. I think forcing the use of decorators makes the code needlessly more complicated

• more confusing to read
• harder to follow another person's code
• harder to see the overall design of the app's routes and rest api
• harder to find and adjust all url patterns

4. Perhaps most importantly- this adds another level of learning required (increasing the barrier) for inexperienced programmers who are the target audience of tethys.

[swainn]

Hi @rileyhales thank you for providing feedback. We discussed your suggestions and our responses to your points are below:

Dropping support for a feature without a major version change introduces breaking changes and is inherently non-backwards compatible. It should not be dropped until version 5.0. Otherwise version 4.1 will not be compatible with version 4.0 and all conventions for checking versioning will fail. For instance, the tethys app store will need to become ultra specific about what version of tethys an app can run on.

The reason for the deprecation warning is to point out that we are breaking with semantic versioning on this feature in favor of an easier migration path for app developers moving apps from 3.0 to 4.0. We recognize, that technically this would introduce a breaking change between minor versions, but the warning is intended to motivate people to migrate immediately, and not wait for 4.1 to do so. Perhaps there is a way to make this more obvious or apparent in the message? The alternative will be to drop support for the url_maps() method entirely with the 4.0 release, we won't be waiting until 5.0 to do so.

Decorators should not become the only option because the core Django project still instructs you to use a urls.py file. Some python frameworks give you the option of using decorators but this is a Django based software. I don't have a problem with including the ability to use decorators in addition but not in place of the core Django way. Refer to the Django tutorial where it instructs you to list your url routes in urls.py. https://docs.djangoproject.com/en/4.1/intro/tutorial01/#write-your-first-view.

Although Tethys is built on Django, we have abstracted away several aspects of development, including how urls are defined. That said, although decorators are the recommended approach, you may still use UrlMaps in the app.py by overriding the register_url_maps() in Tethys 4.0. See: SDK | Routing API | UrlMaps and SDK | Routing API | register_url_maps

I think forcing the use of decorators makes the code needlessly more complicated
more confusing to read
harder to follow another person's code

Our motivation for moving to decorated controllers was to simplify development:

• One less file for users to be worried about when creating new views (i.e.: don't need to open up app.py to define the URL).
• Easier to see which URL is associated with which controller function/class.
• Decorators have been used in Tethys for a while to allow users to retrieve workspaces, set login_required, etc. The controller decorator now merges all that functionality into one decorator, simplifying the process.
• From the perspective of what we can do to further lower the barrier for our developers, having every controller decorated provides more control the request lifecycle hopefully leading to additional simplifications in the future.

harder to see the overall design of the app's routes and rest api
harder to find and adjust all url patterns

One feature we can add to aid with this is an inspect command that can, among other things, list the routes of a particular app.

Perhaps most importantly- this adds another level of learning required (increasing the barrier) for inexperienced programmers who are the target audience of tethys.

We believe decorators will simplify development for new developers (see reasons above).