Promote the appup plugin to core component?

[ferd]

https://github.com/lrascao/rebar3_appup_plugin

This plugin by @lrascao has been maintained for years, aligned with all the same requirements we have for rebar3 itself, and I've personally tried it a few times when working with relups and it functioned well.

I think that by now @lrascao has proven that he'd be reliable as a maintainer, no other plugins seem to have made a similar dent in the landscape. If he's open to it, it might be worth it for us to promote his plugin to be in core rebar3 functionality since it's appearing sustainable.

The license is compatible as well.

I haven't discussed it with anyone before, but this issue could be a good place to do so.

---

A few of the things I have concerns about:

Are we okay with the design and UI approach of the plugin? It seems to integrate tightly with a git or hg environment that assumes all branches and concurrent development takes place within one directory. I think however that the current relup command has the same limitation or behaviour, where it expects all the data in the same _build directory.

There are about 8 issues and 4 PRs currently open in the plugin. These are probably things we'd want to close before importing them, since if there's any API change expected, it would make sense to do it before we freeze the code within a guarantee of rebar3.

Are there other API changes that would be worth it in there? It makes sense to do them all before we pull things in.

Documentation would need to be added. I think this would represent work within a greater "how to structure your development to align well with hot code upgrades".

Other maintainers (see: @tsloughter) need to approve. @lrascao needs to provide approval as well. If he's not interested, we won't be bringing this in either.

[lrascao]

Regarding of what means to be a part of the core functionality, would the plugin then be a part of the rebar3 binary? This probably would not appeal to everyone

[ferd]

yeah essentially this would require taking the command and all the code, moving it to the rebar3 project, and then it would be standard command like relup or compile, though I guess it could be doable as a dep.

[lrascao]

i'm generally ok with this direction, but maybe a simpler (and cheaper) first step is just adding the plugin to the rebar application template or other forms of usage promotion, this allows to test the waters regarding adoption/acceptance while at the same time improving documentation and fixing issues

On Fri, Jun 7, 2019 at 1:04 PM Fred Hebert [email protected] wrote:

yeah essentially this would require taking the command and all the code, moving it to the rebar3 project, and then it would be standard command like relup or compile

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/erlang/rebar3/issues/2103?email_source=notifications&email_token=AAE4DN7IPMIXGOGWVMOHPKDPZJFFVA5CNFSM4HVEFVIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXFT75Q#issuecomment-499859446, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE4DN54RBHQWYHJXXBWFELPZJFFVANCNFSM4HVEFVIA .

-- PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260

[ferd]

I think it's generally fine to provide commands even if not everyone will use them. For example, tree or xref might be used by a fraction of users. Mostly I see the appup plugin as a real nice step to fill the gap between release and relup, where otherwise everything must be backfilled by hand.

The one thing I'd like to figure out is how to encode the best practices to easy development cycles with hot code loading. For example, relup reorders things such that apply instructions always take place after upgrades, so if your upgrade requires something to be started or stopped by hand before it takes place, you kind of get in a weird spot. If you require a supervision tree to be restarted, that's an upgrade, but the cross-app ordering is not obvious to handle in such cases either.

So there's probably a way to cut up development and releases that would cater to that better, but I'm trying to figure out what it is that would make things simpler.

[ehohenstein-imvu]

It's very disappointing that the feature provided by this plugin is not part of the core functionality. Support for hot code reload is IMO the primary reason to use rebar over simpler tools like make. Hot code reload relies on appup scripts and automatic generation of appup scripts is very important as writing them by hand is both time consuming and error prone. Why have the relup feature part of the core functionality without appup? Both features were part of rebar v2.

I was in the process of a long-overdue migration from rebar to rebar3 for a project I maintain but the fact that this feature is provided by a plugin makes it impossible for me to perform this migration because:

1. the latest version (currently 2.4.6) of rebar3_appup_plugin has a bug that causes it to crash with the project I'm working on (and perhaps any project with a library module) - see https://github.com/lrascao/rebar3_appup_plugin/issues/73
2. rebar3 does not appear to support specifying the version of a plugin
3. my company policy requires that all dependencies are cloned/mirrored internally to our company and sourced from said clone/mirror rather than directly from the internet and rebar3 appears to only support installing plugins from hex - hex can be mirrored but I don't see any documentation for how to use a hex mirror for rebar3
4. The project I'm working on uses hot code reload for continuous deployment of a stateful service (maintaining long-lived TCP connections to clients which cannot be severed by a restart)

[tsloughter]

Plugin and Project Plugin dependencies can be from any source (meaning, source mirror works fine, it does not have to be hex).

[ehohenstein-imvu]

Plugin and Project Plugin dependencies can be from any source (meaning, source mirror works fine, it does not have to be hex).

I could not find any documentation for how to do this. If there is such documentation, could you please point me at it? If there is not, what would it say?

[ferd]

any of these value formats should work: https://rebar3.org/docs/configuration/dependencies/#declaring-dependencies

[ehohenstein-imvu]

That documentation is for how to declare dependencies, which may come from git or they may come from hex, but not how to configure a hex mirror. However, I believe I've answered my own question which is to either use the HEX_CDN environment variable as documented here: https://rebar3.org/docs/configuration/configuration/#environment-configuration

Alternatively it should be possible to specify a hex mirror in the hex section of the rebar.config file as documented here: https://rebar3.org/docs/configuration/configuration/#hex-repos-and-indexes

I haven't tried either of these solutions yet but it seems they may do what I need, allowing me to use the appup plugin.

[ferd]

Oh yeah I meant to say you can just declare the plugin as any other dep and use the same {appname, {git, URL}} format for it. That's the right spot for the hex mirroring too yeah.

[ehohenstein-imvu]

Oh yeah I meant to say you can just declare the plugin as any other dep and use the same {appname, {git, URL}} format for it. That's the right spot for the hex mirroring too yeah.

At first when reading that comment, I thought you meant to put the plugin into the deps block of rebar.config as {rebar3_appup_plugin, {git, ...}}. I tried that and it did not work. I tried putting that into the plugins block, however, and that did indeed work. Re-reading your comment, that is clearly what you meant. I had read the code for rebar3 that handled plugin configs and I didn't see anything to handle any plugin config besides the name but I guess I didn't look at it carefully enough. Thanks!

I could do a better job of reading the documentation as this is what is says on the documenation for rebar3 plugins: "Plugins required for building an application should be included under plugins in the same format as dependencies are listed in deps."