Point at a local installation for dev purpose

[glaforge]

As a Groovy developer, I often install development versions of Groovy locally.
It's usually the master branch of upcoming Groovy releases, etc.

It'd be nice if I could tell GVM to use my local installation as well, in addition to all the known release versions. For example:

gvm install local groovy 2.1.0-SNAPSHOT /dev/groovy/master/target/install

Or something like that. I'm sure you'll find a better command-line to use.

[pledbrook]

Do you want this tied to a particular version or a generic dev label? The path you give in the example could change its version depending on what branch you're on.

I have to say, I normally work with a dev installation that changes its version based on what branch I'm on (and I may explicitly change the version myself).

[glaforge]

That's a good question.
Perhaps the mechanism I'm after is the ability to define any custom local label I'd want?
Rather than just one single mandatory label.
Anyhow, even with just that one label that'd already fulfill my need.

[marc0der]

I'm thinking along the lines of allowing multiple labels. You would then be able to point any of these labels to any directory on your machine. In other words, you wouldn't need to go digging for it in your .gvm folder.

This would then allow support for a single dev version, or multiple versions like 2.1.0-SNAPSHOT, 2.2.0-SNAPSHOT etc.

[marc0der]

The local development candidate feature is now available for testing on our test environment.

export GVM_SERVICE="http://test.gvmtool.net"
gvm selfupdate

Don't forget to source the gvm-init.sh after the selfupdate, otherwise it simply won't work ;-)

You can now perform all the commands except listing of candidates. If you attempt to list, the local version simply won't show up in the list (yet). I'll be looking at implementing this shortly.

For now, please read the cucumber feature for local development versions which should make the usage very clear.

/cc @graemerocher

[graemerocher]

Thanks Marco... will give a go!

[glaforge]

On my Mac, when sourcing gvm-init.sh I got:

glaforge-mbp:groovy-git glaforge$ source "/Users/glaforge/.gvm/bin/gvm-init.sh"
uname: illegal option -- o
usage: uname [-amnprsv]

[glaforge]

But apart from that uname problem... the local installation worked fine for me, and I could use my local version!

[marc0der]

Thanks for picking that up. The error that you are seeing is due to something else I was working on. Looks like the Mac version of uname is a little different from other platforms.

[graemerocher]

Yeah I also noticed the uname problem, also if you do "gvm list grails" it doesn't display local builds, not serious but for consistency maybe it should? Otherwise works great!

[pledbrook]

@graemerocher You might want to read his comment with the bold statement 'You can now perform all the commands except listing of candidates' 😉

[glaforge]

But since when do we have to read comments, manuals, tutorials, documentation and what not? :-D

[marc0der]

@graemerocher yes, I'll be releasing the listing within the next day or so.

[graemerocher]

@pledbrook Wow, I think because it was in bold I just skimmed over that 8D

[pledbrook]

Switching from a local installation to a standard one doesn't seem to work. Will investigate.

[pledbrook]

OK, so gvm-use.sh is still assuming a numeric version number when it updates PATH. A quick fix to the regex should work fine. We should probably forbid '/' in labels though, otherwise that's going to really screw gvm up.

[pledbrook]

I'm struggling to get a Cucumber test that reproduces the problem :( This is passing, even with the broken code:

Scenario: Switch from a local version to a standard one
    Given the candidate "groovy" version "2.0.5" is already installed and default
    And the candidate "groovy" version "2.1-SNAPSHOT" is already linked to "/tmp/groovy-core"
    When I enter "gvm use groovy 2.1-SNAPSHOT"
    Then I see "Using groovy version 2.1-SNAPSHOT in this shell"
    When I enter "gvm use groovy 2.0.5"
    Then I see "Using groovy version 2.0.5 in this shell"
    When I enter "gvm current groovy"
    Then I see "Using groovy version 2.0.5"

@marcoVermeulen Any ideas?

[marc0der]

@pledbrook Strange, but I can't replicate what you are seeing. I've run through your scenario manually and it works perfectly on my side.

Can you tell me what the exact steps are that you take?
Do you have the latest code from http://test.gvmtool.net?

[pledbrook]

Is that because you use a label that starts with a number? Ah ha! That's why the test succeeds. I should be trying with a label of 'dev'. Doh!

[marc0der]

Ah, okay. I can replicate it as well now. Well spotted! Are you going to be looking into this one or should I fix it?

[pledbrook]

I have a simple fix and cucumber test, but now I'm getting a whole bunch of cuke test failures unrelated to my change. The failures almost look as if aeroplane mode is misfunctioning in the tests.

[marc0der]

Do you perhaps have a local server running on port 8080?

[pledbrook]

Yes. Perhaps the tests could fail with a big error message about 8080 already being in use? 😄 Anyway, changing the feature to use dev hasn't impacted the Cucumber test, so it's still not reproducing the problem. I don't really want to commit a fix until there is test coverage for it.

[pledbrook]

Is this because the local_developement_versions feature is not running in isolated mode? Are the tests not all running once in isolated mode and then once not in isolated mode?

[marc0der]

No, they're not run in both modes. They should be run with isolated mode enabled. In fact, I'm thinking of stripping out the isolated mode configuration. Isolated mode is proven to work well and is default behaviour by now. I'm all for just keeping it simple.

[pledbrook]

OK. Well I've pushed fix + two scenarios (one with isolated mode active, one without). I'm OK with only having the one mode of operation now, but before going 1.0 we should sort out the variables as you've mentioned before. Although they aren't visible via the env command, you can still do things like echo $CURRENT. I'll raise an issue.

[marc0der]

Agree. About isolated_mode, I can look at it this weekend after finishing this feature.

[marc0der]

@graemerocher I've pushed the changes for listing local dev versions. Cukes can be found here.

I've deployed it to the test environment as before so give it a go.

[graemerocher]

@marcoVermeulen Nice! will give it a go

[marc0der]

Okay guys, not hearing anything back from you so presume it's working...

Closing this issue.

[glaforge]

It's indeed working fine.
Sorry for not replying earlier.

On Tue, Jan 22, 2013 at 10:12 PM, Marco Vermeulen
notifications@github.comwrote:

Okay guys, not hearing anything back from you so presume it's working...

Closing this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-12566745.

Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/
Social: @glaforge http://twitter.com/glaforge /
Google+https://plus.google.com/u/0/114130972232398734985/posts

[marc0der]

No probs :-)