Remove the project wide "default" Devkit setting

[Azolo]

With the release of Ruby 2.0.0 we started using a new compile environment. With the new environment it no longer means there is a universal default.

Instead a default-devkit should be included in each interpreter configuration and be used when DKVER isn't supplied.

Likewise building a Devkit should error out without a supplied "DKVER".

@jonforums Can you think of any problems with the purposed behavior?

[MarkDBlackwell]

Point 1:

With the release of Ruby 2.0.0 we started using a new compile environment. With the new environment it no longer means there is a universal default.

Just to clarify:

1. By "compile environment" (and "environment"), I suppose you mean "DevKit type" (or "flavor"); and
2. By "universal default," I suppose you mean "a single DevKit type which succeeds with all the allowed Ruby versions."

Presumably, the allowed Ruby versions are those available via RubyInstaller's Rake tasks (without users overriding them through override/*.rb code). By design, given each ruby_base_version pair of major and minor version numbers, RubyInstaller preselects and makes available only one version of MRI Ruby (YARV or CRuby). As you say, currently rake ruby19 and rake ruby20 (for example) require different DevKit types.

Is all this correct? :)

BTW (as point 2), in the Rake commands rake devkit:ls and rake ruby22 DKVER={{something}}, I found remembering which name to enter (of DevKit and DKVER) not as easy as it may be for you, indeed, old hands. Perhaps this is because DevKit and DKVER both IMO seem to be names for the same concept. In these two particular usages, are they in fact the same concept? If so, then having two names here is IMO a misfeature.

Obviously, DKVER is not a version number. (And, of course, version numbers definitely would happen, if any long-range plans to gemify the DevKit types are implemented. That would make the name DKVER even more confusing.) So IMO a better name for DKVER would be devkit_type (lower-case, even for the environment variable).

Point 3: On that last topic, as you know, half the time, because it's easier and it works (generally, environment variables aren't case sensitive on Windows), people use lower case when entering environment variables such as your DKVER and SFX. These instances of double specification are confusing to new users. So why not always speak of lower-case environment variable names? For instance, see your wiki page section Building the DevKit.

you can always build your own DevKit by simply:
rake devkit sfx=1

Point 4:

Instead a default-devkit should be included in each interpreter configuration and be used when DKVER isn't supplied.

A better name for default-devkit IMO would be default_devkit_type.

Point 5:

Likewise building a Devkit should error out without a supplied "DKVER".

Currently, the output of rake --tasks includes:

rake default                   # Build Ruby 2.3

Going further than your suggestion, building a DevKit (or an installer) should also error out IMO without the user supplying a ruby_base_version. Thus no Ruby version would be defaulted to.

Point 6: And when are devkit_type (DKVER) and base_ruby_version picked up from what has been generated already, and when not? That's further confusing. People (even moderately new users) might assume one or both will be picked up sometimes, although perhaps they won't—I know I did. Requiring users to specify both always (or the task immediately fails) is IMO less confusing and less time-wasting.

Point 7: The default Rake task IMO should be reserved to invoke (future) tests for RubyInstaller (combined with user overrides). By essentially-universal convention (as you know), :test is the default task (where tests exist) because it eases the test cycle.

[Azolo]

By "compile environment" (and "environment"), I suppose you mean "DevKit type" (or "flavor"); and

Yes

By "universal default," I suppose you mean "a single DevKit type which succeeds with all the allowed Ruby versions."

No, they should all more or less succeed but the DevKit for each version is coordinated with the rake-compiler project. With Ruby 2.0.0 that changed and in the near future it will probably change again.

As for the changes you suggest in your post, they aren't bad ideas or changes but you have to consider that people have used this software and have scripts around it. The external API may not be pretty but it's what we've got at the moment and it works well enough. So while good reasons I don't find them good enough.

As for the tests, there are certain parts of RubyInstaller that can be refactored to be tested but the Rake parts would be near impossible to test properly. It would be like writing tests for a Makefile. So outside of some major refactoring writing tests would be not worth the effort at the moment and it would be testing modular parts that could be used by the rake tasks and not the process itself.

I don't want to make any breaking changes on how it works in the expected usage now, but I do want to make it harder to make the mistakes that you mentioned and possibly add wrappers around them for convenience.