[feature request] new field sdk/compiler for determine compatibility

[boozook]

I mean what will be great if in the each lib haxelib.json contains field about compatible & tested version of Haxe compiler+std.

[nadako]

This sounds useful indeed! Also consider npm implementation: https://docs.npmjs.com/files/package.json#engines

[boozook]

I like impl. in the NPM. Couple of things:

For implement this feature we need to fully support semver. As i know now it is not (really?).

---

In the NPM impl. note:

Note that, unless the user has set the engine-strict config flag, this field is advisory only.

I think we do not have to create new define as there engine-strict. Instead it I see two options:

1. Fields "sdk"/"haxe"/"engines"is advisory only constantly and ever.
2. If these fields are present in haxelib.json => Haxelib have to strictly test fact of existing and version of each tool. Question how? because then we need a "where-to-look"- and "how-to-ask-version"-scheme for each possible third-party tool. (Getting the version of Haxe isn't a trouble because the compiler runs Haxelib in interpret mode and we have defines such as haxe_ver. ).

Anyway this fields must be optional of course for for backward compatibility.

Format and field-names variants:

• "sdk" or "haxe" or "compiler": { "sdk" : ">=3.0.0 <3.3" }
• "engines" or "tools":

{
  "engines": {
    "haxe": ">=3.0.0 <3.3",
    "node": ">=0.10.3 <0.12",
    "protoc": ">=3.0.0"
  }
}

Now new question: What kind of things can be specified in "engines"? Only executable cli-tools or maybe dynamic libraries or .so?

[nadako]

Correct me if I'm wrong, but I think NPM only supports hard-coded stuff like "node" and "npm", so it's not as pluggable as it seems. Maybe we should keep it simple only support "haxe/sdk/compiler/whatever".

I think it should be only advisory and the only thing it should do is emit a warning on installation (IIRC that's also how NPM works).

You're right about semver comparisons, we should first implement that, but there's still no consensus (see #81), so we have to delay this one until we agree on some version management mechanism.

[boozook]

Correct me if I'm wrong, but I think NPM only supports hard-coded stuff like "node" and "npm", so it's not as pluggable as it seems. Maybe we should keep it simple only support "haxe/sdk/compiler/whatever".

Yes. Then maybe first variant ("sdk" or "haxe" or "compiler": { "sdk" : ">=3.0.0 <3.3" }) and then we can use already existing dependencies part like this:

{
  "name": "openfl",
  "dependencies": {
    "lime": "",
    "haxe": ">=3.0.0 <3.3"
  },
}

and in Haxelib check hardcoded lib-names like haxe or haxelib.

---

NPM only supports hard-coded stuff

Not sure because found { "engines" : { "iojs" : "1.6.1" } } in that post and never used this feature.

[ibilon]

dependencies has the meaning of "add this lib to the compilation"
so unless haxe becomes a haxelib package (which would be cool) it's weird here.

[nadako]

agreed

[boozook]

:) If Haxe becomes a haxelib package we will obtain real true virtual environment like one for Python. That will be cool.

[nadako]

I don't see how this (haxe as lib) could be easily done and tbh don't want to think about it at least for the forseeable future. The original "compiler" field idea is still worthy IMO.

[ibilon]

A simple proxy exe which sends all its arguments to $(haxelib path haxe [version])/haxe with the required haxe_std env var should work without too much issues I guess (hope).

Thanks to Andy knowing about/getting updates on linux isn't an issue any more, but mac or windows it's still there,
but that's another issue.

The haxe field could still be used to warn about a haxe version too low (or too high?) for the lib the user is trying to install.