Control Lime version per project?

Lime
#1

I love the ability to specify haxelib versions inside the project XML. However, specifically with Lime, I see some odd results.

<haxelib name="lime" version="2.3.3" />

Here are my observations (I am targeting HTML5 - have not tried other targets):

  • If not specified in the XML, Lime uses the computer’s set current version. This is as expected.
  • If I DO specify a Lime version inside the XML, the computer still uses the current set version. Additionally, it triggers a build failure if the XML specified version is not installed. I thought this was at least helpful because I can draw attention to the set version to minimize errors.
  • Since OpenFL3 (3.0.3), including the Lime version in the project XML seems to trigger different settings than not including it. I see a slightly different ApplicationMain generated, and it forces me to extend lime.app.Application from Main. Also, NOTHING renders to the screen. Even if I do a really simple Lib.current.graphics draw(). Lib.current.stage is reporting null.
  • If I DO NOT specifiy Lime in my project XML using OpenFL3, the project compiles and runs just fine. Main can extend Sprite with no issues, and it can ALSO extend lime.app.Application with no issues. Everything renders and works as it should.

So my question here is: am I using Lime in error by trying to specify a version? Why do we see such different behavior? It would be very valuable to me to be able to lock Lime version per project because I have one computer building many projects that are guaranteed to be on various Lime versions. This behavior works just fine with any other haxelib.

Thanks in advance for clarifying anything I’m missing or looking into providing this support!

1 Like
#2

You need to change the openfl version, openfl auto include lime into your project, take a look at include.xml inside openfl.
I don’t think its a good idea to use a newer version of openfl and an old lime version.

If you are using an old version for compatibility reasons try using <set name="openfl-legacy" /> or <set name="lime-hybrid" />

#3

Thanks for the fast reply. I should have added that my tests were using the following pairs of libs:

  • openfl 2.2.5 with lime 2.1.0
  • openfl 3.0.3 with lime 2.3.3

So you’re saying that each openfl version automatically pins a version of lime? I’ll look for that include.xml file you mentioned, but I am still curious why it just uses whatever my set version is in haxetoolkit. This seems to be independent of openfl.

Thanks!

#4

OpenFL uses <haxelib name="lime" />, which should prefer the latest installed version. I would love to see “wildcard version” support, so we can pin, say, OpenFL 2.2 to Lime 2.1, etc

#5

Hi Sing! So in that case you cannot use the version flag for each OFL release?

<haxelib name="lime" version="2.2" />
#6

You cannot say version “2.2”, you’d have to say “2.2.0”, but in that case if a fix is publish as “2.2.1” then the openfl version wouldn’t use it, unless each patch of lime induced a patch of openfl.

#7

…which becomes a “chicken or the egg” type problem. We basically need a smarter haxelib, or haxelib-type smarts within the Lime tools, to solve this one (but I’d love to see it)

#8

Thanks for the info, you guys! So (last question) in this case can someone explain to me the difference in including a specific haxelib lime version in my project XML? In my original post I mentioned seeing different results if I specify a version vs not. If I do specify lime, it seems to break my openfl3 project (but works fine for openfl2 with associated lime specified). If I remove the lime include, it works totally fine. Is this conflicting with the instruction inside the openfl include? Basically my next thought is that I’d like to reference it in my project XML so other coders know what lime to be using and will get warnings at compile time. But it sounds like we should totally avoid specifying Lime inside the project XML. Maybe what I should do instead is set a compilation flag for the Lime version (#if lime < “2.2.2”) #error. Thanks again for your expertise!

#9

Hmm, I guess there is a little issue here in controlling the version

If I recall, I think the tools will prefer a specific version if other generic libs are included:

<haxelib name="lime" />
<haxelib name="lime" version="2.2.0" />
<haxelib name="lime" />
<haxelib name="lime" />

Even though three references imply the latest, I think the one specific version request may override the others, I could be wrong.

There is one thing that changed in Lime/OpenFL interaction, though. Before, you either would use Lime alone, or OpenFL on top of Lime, but now you can use Lime and OpenFL together. If you include Lime before OpenFL, it disables the OpenFL templates. Basically, it’s done to allow you to boot OpenFL yourself, like:

https://github.com/openfl/lime-samples/blob/master/HandlingInputEvents/Source/Main.hx

#10

FWIW I was specifying Lime before OpenFL in my project XML, which would explain the odd behavior I was seeing. I will try flipping the order to see if it still overrides.

But yes, I think my solution here will be to just have a compiler flag in Main.hx to catch the set version of Lime and control it that way. Thank you!! Hopefully one day this becomes available.

Update: I have been using the compiler flag method for my projects and has been working nicely from my Main.hx. It’s not as good as the project.xml simply setting the version, but definitely a good backup plan for those who need to control Lime.

#if ( lime != "2.3.3" )
#error ""Lime 2.3.3 is not active - please set it."
#end
#11

You can also try greater than and less than, Haxe does string comparison, so “2” is less than “3”, but “10” is less than “2” if that makes sense (“1” < “2”)

#if (lime < "2.3")
#error "Please use Lime 2.3+"
#end
#12

So is it still required to manually set the default lime version in haxelib between projects?
Theoretically, lime tools could look at the lime version request in project.xml and redirect the call to other version’s lime tools?

#13

No, the situation hasn’t improved. A couple months ago, I looked into setting something like this up. I even started editing Lime’s codebase, but I gave up after maybe 4-5 hours, when I realized how much longer it was likely to take.

My advice is to write a script that calls haxelib set lime #.#.# and haxelib set openfl #.#.#. This takes practically no time to execute, so you could automatically run the script before each build. (Now that I think about it, HaxeDevelop doesn’t want you to set a custom pre-build script. If you haven’t switched to VS Code yet, now might be the time.)

Library version proposal
#14

Playing with it further, I found out that it’s kind of possible to build a HaxeFlixel app with lime 5 and openfl 5 chosen in haxelib like this (order matters):

<haxelib name="lime" version="2.9.1" />
<haxelib name="openfl" version="3.6.1" />
	
<haxelib name="flixel" />
<haxelib name="flixel-addons" />

But it only works until cleaning the project :frowning:

#15

I think we can resolve this with wildcard version support. For one Lime release, I included a custom version of haxelib to add this feature, but I reverted it in fear that it would clobber studios that maintain (and need) their own custom version of haxelib. I have a fork of haxelib with support for wildcard versioning and local directories (similar to dev, but it does not “override always”)

The good news is the haxelib included with Haxe 3.4.2 and greater currently supports haxelib dev haxelib path/to/custom/haxelib, and current Lime tools support lime rebuild haxelib, or you can haxe client.hxml from the root directory of a custom haxelib project.

If you have wildcard version support, then OpenFL can include <haxelib name="lime" version="5.0.*" /> (and similar) instead of using whatever the current version is.

I do not want to force OpenFL to pair directly to minor releases of Lime, in case we release a patch for Lime.

Current OpenFL releases should also allow you to include Lime before OpenFL (with your own version) first, which should help a bit with deadlock:

<haxelib name="lime" version="5.0.1" />
<haxelib name="openfl" />

For what it is worth, I re-released OpenFL 3.6.1, hard-coding Lime 2.9.1 as the version.

What really needs to happen, though, is OpenFL 4 or OpenFL 5 support in Flixel :cry:

#16

Does that mean that

<haxelib name="lime" version="2.9.1" />
<haxelib name="openfl" version="3.6.1" />

should already work? Why are wildcards needed in this case?

This setup appears to work, because the project was previously compiled with lime set to 2.9.1 in haxelib, I can add code and build and run. But after cleaning the project it’s broken

#17

The goal of the wildcards would be that you use <haxelib name="openfl" version="4.0.0" /> and OpenFL would automatically pick the best compatible version of Lime. Then you could pick an OpenFL version, and the rest would be handled. That, I think, is the best long-term solution, but for now, we have to wait until it becomes a standard haxelib feature

#18

I get it, I mean how does automatic version picking help if even manual picking doesn’t fully work? Or it only doesn’t for old lime?

I have new lime set in haxelib and want legacy lime to be compiled in, and explicitly set all the versions in project.xml, is there any thing that prevents newer lime tools to get other lime versions into the project?

Also I’m interested in version picking per project not only for supporting HaxeFlixel projects, but also to intentionally freeze all dependency versions for a particular project in certain phase of development.

Thank you!

#19

We’ve been working on improving version locking tools. Unfortunately, every improvement we make is not retroactive. Using an older version causes us to run the older tools, which don’t include the fixes we made

You could, however, try haxelib newrepo with a local version of the older OpenFL/Lime, I believe that should work fine so long as you use the same working directory when you build