Open tsloughter opened 5 years ago
I would probably suggest going for a kind of mode
setting with values like dev | prod | embed
that impacts defaults: dev is just the quick symlinked release, no tarball, debug_info is in, neither src nor erts is in. Prod is a portable self-contained tarball (and release). It carries its own erts, src, debug_info. Embed is the fully stripped one, but has to include erts and libs as well.
Each option specifies what the 'mode' selects otherwise. I would default to prod. One reason is that dev mode is often broken on windows, due to symlinks. Not sure if it is still the case.
Good point, I like that. Only issue is embed
is such an overloaded term and may be confusing. It may be fine and I can't think of a better word right now but is something to consider.
any other term like compact
or minimal
could make sense too I guess. The idea is to provide the smallest possible release that is portable.
Wish: Removing obstacles of including relx in OTP which then makes it easier to include rebar3 in OTP
@peerst yea, there is a lot of overlapping functionality between rebar3 and relx. It likely makes the most sense to add release functionality from relx directly into rebar3 and remove the dependency all together.
There needs to be a discussion with the OTP team about the future of reltool and if replacing reltool requires having a stand alone tool like it or if it being in rebar3 is acceptable.
I'd like to suggest for the {include_src, boolean()}
option when false
to exclude source/doc files from all the apps included in the release (including those that are part of the OTP). As far as I understand presently it only excludes the sources of the apps in the project, but the ones from the OTP are still included with their sources.
Additionally, I find that it would be nice to expand the system_libs
option to be: {system_libs, boolean() | [Path::string()] | AppNames::[atom()|{atom(), none|load}] | all}
. AppNames
would be a list of OTP applications that would not be included in the release package but for which there would be their paths added to the release's script file (e.g. {path,["$ROOT/lib/crypto-4.5/ebin"]})
, so that the release can be booted using the applications already pre-installed on the local machine. The all
option will add paths for all installed OTP apps that come with the distribution.
I believe this is in line with what @ferd suggested for the smallest possible release.
@saleyn hm, I thought it did exclude source from all apps... I'll have to verify in a bit.
Another change I plan to make: enable xref during release creation by default.
Specifically the exref
arg systools
takes to do the checks.
@tsloughter, to verify I did rebar3 new app
, added a release section with a couple of OTP apps, added {include_src, false}
, and ran rebar3 as prod tar
, which produced a tarball containing the OTP app sources despite the explicit include_src
setting. So I wasn't sure if it was a bug or {include_src, false}
was only meant to exclude sources of the apps included in the project tree.
@saleyn thanks, this is a bug then.
I was reminded of another idea from a discussion on elixir slack just now.
Because the releases built to rel/<relname>/
can not be used to build upgrades off each other (since you need to first do a tar
to have systools:make_tar
create a release in the right format for release_handler
to understand for upgrades) there is really not a good reason to keep all of the versions under rel/<relname>
and we may want to split it like rel/<relname>-<vsn>/
or rel/<relname>/<vsn>/
.
I'd like to consider a major release,
4.0
, and am opening this to discuss potential changes that will then be turned into their own issues to be worked on.The first changes I'd like to do that break compatibility are some new defaults:
extended_start_script
: new defaulttrue
sys_config
/sys_config_src
andvm_args
/vm_args_src
: I think these should be picked up automatically fromconfig/sys.config[.src]
andconfig/vm.args[.src]
if those files exist or the config entries are defined.I use
dev_mode
less and less these days sincerebar3 shell
has improved a lot, so I am less sure these are necessary but they are worth considering:dev_mode
: new defaulttrue
include_erts
: either defaultfalse
or have it be based ondev_mode
The point of these changes I'm trying to make is to simplify the base configuration most users would have. Today almost all I see have these values set exactly the same.
With a similar intent of simplification I think the next release should consider renaming the boot script to
start.boot
. This is described in a jira issue I opened, https://bugs.erlang.org/browse/ERL-859, but basically the issue is that the release created in therel/
directory and a release tarball have different names for the.boot
file. The former being<relname>.boot
and latter beingstart.boot
. This can be confusing and Elixir 1.9's release support simply renames tostart.boot
.Another interesting thing
mix release
does is always create a tarball. It is minimal overhead to create from a already generated release but may be a little tricky because of ourdev_mode
. But something to consider doing and removing.Adding
prod_mode
. This doesn't require a major release. The setting would enable a number of common settings that are usually listed manually,{debug_info, strip}
,{include_src, false}
,{include_erts, true}
,{dev_mode, false}
.Last for now is removing the goal/constraint solver. This gives the ability for relx to act as the tool that does dependency resolution on constraints and chooses from multiple available versions of an application. But since relx is, as far as I know, always used on a project that has already resolved deps and gives it a list of the exact application versions to include, it is not needed and only adds complexity and confusion. This is one I guess we should verify no one uses but even if someone does we likely should drop it as they have other options for this (rebar3) today.
Edit: Just realized another potential improvement is removing the use of
systools:make_tar
. I did a quick profile of arebar3 tar
and the top time sink looks to be zlib deflating. This is done because relx first callssystools:make_tar
, it then unpacks that tarball to add additional files defined in the overlays.Building the tarball directly in one go, instead of having to compress twice, should save us a good bit of time, but it should be verified first.
Edit: Scratch that last part, I think I might be able to convert some of the custom shit we do to the tarball into options for
systools
. Then we'd not need to unpack/repack but can still just callsystools:make_tar
.