Update lfetool to use LFE 0.9.0

[ghost]

The LFE branch on github.com/rvirding/lfe has switched to 0.9.0 and creating a new project with lfetool new service blah fails on the dependency check for ltest ("0.8.0" expected, "0.9.0" found).

[oubiwann]

I'm still traveling, but am trying to get things with lfetool to a stable state. This will probably mean fixing the current lfetool to explicitly use 0.8.0. [See footnote 1]

Here's what needs to be done:

• immediately, update lfetool to explicitly use the same LFE version that dependency projects (lunit, ltest) are using (0.8.0)
• at a later date, create an lfetool stable branch, and then update all the docs to point to that location (so the docs don't have to be updated when a new version is released) [See footnote 2]
• also at a later date, update all the lfetool dependency projects to use 0.9.0
• then update various rebar.config files to use the new versions of the dependencies
• after that, update lfetool to use 0.9.0 (this ticket)

I will create (or update) tickets for these.

Footnotes

[1] Thanks to the way that rebar handles (or doesn't handle) multiple versions of the same project, to support 0.9.0, I will need to update all projects that lfetool uses as dependencies when it creates skeleton projects.

[2] This is necessary to support older releases of lfetool that are still in use, which depend upon the master branch being where it currently is

[oubiwann]

Oh, I meant to also add the work-around until the bug is fixed:

• create a new project and ignore the error message(s)
• cd into the new project and update rebar.config's entry for LFE:
  • change .* to "0.8.0"
  • change "master" to {tag, "v0.8"}
• rm -rf deps
• make compile

[oubiwann]

I've created the following related tickets for these issues:

• 112 - Fix lfetool rebar.config files to point explicitly to LFE 0.8.0

• 114 - Create a "stable" branch for use by docs and scripts (this has related tickets #109 and #113)

• https://github.com/lfex/ltest/issues/5 - Update rebar.config to point to latest LFE release, 0.9.0
• https://github.com/lfex/lutil/issues/3 - Update rebar.config to point to latest LFE release, 0.9.0

• 116 - Update rebar.config files to use the newest versions of the deps

[oubiwann]

I'm going to rename this ticket from "LFE master branch has switched to 0.9.0" to what needs to be done, i.e., "Update lfetool to use LFE 0.9.0"

[pigmej]

@oubiwann up on this, any updates / ETAs ?

[oubiwann]

The lfetool dev-1 branch is using LFE v0.9.0.

Once the 1.4 milestone is complete, this (dev-1) will get merged to stable. No ETA on completing the milestone right now, but I myself have been using lfe from the dev-1 branch ...

[oubiwann]

@pigmej I'm going to try to release 0.9.0 support today, if I can get all the necessary tasks accomplished. Outstanding issues I will move to a new 1.5 milestone.

1.5 will support LFE v0.10.0, which I also hope to get out very soon.

[rvirding]

Is it possible for lfetool to get the latest commit on the master branch by default, or perhaps as an option. Commits on the master branch are "release worthy" even if they don't have a version number. All experimenting is doen on develop and other branches. It might be interesting to also have an option which gets the latest commit on the develop branch.

Note I don't know if this is possible,

Robert

On 4 January 2015 at 21:18, Duncan McGreggor notifications@github.com wrote:

@pigmej https://github.com/pigmej I'm going to try to release 0.9.0 support today, if I can get all the necessary tasks accomplished. Outstanding issues I will move to a new 1.5 milestone.

1.5 will support LFE v0.10.0, which I also hope to get out very soon.

— Reply to this email directly or view it on GitHub https://github.com/lfe/lfetool/issues/111#issuecomment-68647184.

[oubiwann]

I've just released lfetool 1.4.0 which has LFE 0.9.0 support. Am getting ready to set up 1.5.0 milestone which will support 0.10.0-dev LFE.

[oubiwann]

On Sun, Jan 4, 2015 at 3:28 PM, Robert Virding notifications@github.com wrote:

Is it possible for lfetool to get the latest commit on the master branch by default,

Using non-versioned repos by default can get a bit messy, strange, and broken at times. It would work for new projects, but say a project is created today that uses all the latest. Then next year, after LFE and other libraries have grown in features, have breaking changes with old code, etc., when that project updates, it's now broken, and in possibly unexpected and hard-to-track-down ways. Not only was I running into this issue, but others in the LFE community had started reporting bugs against LFE, lfetool, and other libraries that weren't actually bugs -- they were just running into breaking changes getting pulled into their projects without being aware of it.

Explicit version numbers is the fix for this.

However, as you and other have noticed, this locks projects into very specific versions, and one has to start updating rebar.config files in the deps directory to get any level of flexibility. That's what this ticket is for (and is complaining about):

• https://github.com/lfe/lfetool/issues/135

Working on the LFE-in-Docker project was absolutely awful for that one reason (everything being locked to specific versions). The "easy" way out in that case was "just" to bundle a deps dir.

or perhaps as an option.

That would definitely be better. There are ways we might be able to do this in lfetool ... but it's really a problem at rebar's level.

If they fixed this issue, much of the pain would go away:

• https://github.com/rebar/rebar/issues/170

Then users could just update their project rebar.config to the versions they wanted, and would never have to do the awful hackery/deps bundling that I had to do for the Docker project.

But, that's not fixed, so we have to work with what we've got :-/

Commits on the master branch are "release worthy" even if they don't have a version number. All experimenting is doen on develop and other branches. It might be interesting to also have an option which gets the latest commit on the develop branch.

Note I don't know if this is possible,

There are a couple of things that come to mind ... but I think we'd have to:

• provide a way of indicating to lfetool that a project should not use the default, version-pinned rebar deps, and
• get the deps to also ignore their own version-pinned deps

I'm not sure if this can be done within the confines of rebar's current feature set. We may have to implement this with bash, LFE, or Erlang.

I'll ponder it some more...

[oubiwann]

I am going to close this issue (since 0.9.0 support is now released); let's continue the conversation about fixing the version-pinning problem in issue #135, "Working with versioned deps can be a nightmare".