Haxelib pains, limitations and its future.

[Adam Harte]

I have been using Haxe for quite a number of years now, and one thing has frustrated me more and more. But first I want to talk about the good.

I love Haxelib! Being able to easily install and keep many great Haxe libraries up-to-date is amazing. Every time I open up an old AS3 project, I cringe at all the third-party libs that are checked into the projects repo.

The amount of open-source projects out there to learn from is amazing. It is always surprising to find examples and full projects that people have gladly put up on GitHub etc.

As great as all these examples are, it is super frustrating to find "the perfect" example that shows off a library feature, only to find that it was build 6 months ago, so is not updated for the very latest version of a Haxelib. I don't know how long I have spent fixing or upgrading other peoples projects locally to get them running with the latest version of a haxelib. Or trying to track down the exact version of a haxelib that the project is assuming. It is quite annoying to revert a haxelib, and have it revert for my other projects.

I realise it is probably better to update the project and make a pull request, but I am sure there is a better way. Especially if I just want to quickly see the end output of a project.

I think this is a valid problem, that I am sure others have come across and have thought about. I know Node.js installs libraries locally using NPM, unless given the -g param. They also have package.json, which contains a list and version numbers of all dependencies. So most of the time, you can download an example NodeJS projects, run npm install, and all dependencies are installed at the correct versions, and no other projects are affected. The dependencies folder (node_modules) is never committed to version control. Only the package.json is.

I don't really know a good solution for this problem with Haxe and haxelib, but seems like the kind of thing others like Node.js have solved a while ago.

I think it is critical to stop the code rot that is happening with open-source Haxe code out there on the web that newbies are getting there hands on. And even having a simple/standard way to say what version of each haxelib a project is built for would be a huge leap. Ideally, I want to just to a git clone of a project, run haxelib install, then run, and it should just run! Don't you think so too?

Cheers,

Adam

[Jason O'Neil]

Hi Adam

I've also struggled with this, as I have several fairly complex haxe projects that use different versions of similar libraries.

The solution I've ended up doing:

1. For each project, have a "haxelibs/" folder that is not committed to version control.
2. When I work on that project, do "haxelib setup haxelibs/" to tell it to use the local haxelib folder, not a global one.
3. Use "haxelib install all" to install all dependencies from the hxmls in the current folder.
4. Try to use specific library version in my hxml files.  For example "tink_core:1.0.0-rc.7"

There are a few things to mention:

• This means you have to re-download libs for each project.  Not a big issue for me, but some libraries like OpenFL are big downloads.
• I think there is a plan to support a local "haxelib" folder in the haxelib client so you don't have to explicitly run "haxelib setup ..."
• Point 4 can sometimes lead to version conflicts (trying to use both "tink_core:1.0.0-rc.6" and "tink_core:1.0.0-rc.7" at the same time) which can be a real PITA.  Support for semver in specifying versions will go a long way to help...

Jason

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Dion Whitehead Amago]

This is spot on. And totally agree with this being a solved problem regarding npm. We should stop wasting time and simply copy all their good ideas so we can spend more time on actually interesting problems. The haxe ecosystem will benefit enormously from removing the barrier of outdated libraries. Even the people who write the libraries won't be under continuous pressure to keep up to date contributed projects.

[Chris D]

I have been doing some npm projects recently and although its not perfect the local packages, npm shrinkwrap and dedupe at least provide the tools necessary to make maintaining and publishing complex dependencies easier. The problem is more than just local packages, its the nested dependencies of the local packages.

There is an issue for this already https://github.com/HaxeFoundation/haxelib/issues/141. 

@Jason's workflow is far from ideal for multiple projects. I believe that npm itself was greatly responsible for the growth of that community. The scope to where npm is in feature set is pretty large, its almost tempting to suggest that it's a good solution for Haxe projects :/

[Philippe Elsass]

The issue mentioned by Adam Harte seem to be more about the fact that projects are built without specifying the version of libraries used, so if you get a project later you can get incompatibilities.

 

It might make sense to have a way to get a list of the versions of the libraries used by a project and to be then able to set all the libraries to the right version at once. If that's a small JSON file you would just store if on Github.

 

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Chris D]

Thats definitely the first problem to be solved. At minimum we need a manifest file similar to a package.json and a way to do a fresh install based on that manifest.

The real issue then becomes people don't follow sem-version strictly :/ So having this feature at least lets us revisit and or distribute a project so that can be built with the same dependencies it was developed with.

I would call it a must have for any package manager.

[Nicolas Cannasse]

Le 08/12/2014 00:49, Adam Harte a écrit :
> I have been using Haxe for quite a number of years now, and one thing
> has frustrated me more and more. But first I want to talk about the good.

Since it's been several times people have asked about it, I took time to
implement local repository in haxelib.

"haxelib new" will create a local repository (in your project root dir)
"haxelib delete" will delete the local repository (if there is any)

When you have a local repository, all your haxelib installs etc. are
done in this directory.

I still have to handle the NDLL resolution in genNeko and I think Hugh
will have to handle a similar thing in genCPP

Feedback appreciated

Best,
Nicolas

[Hugh]

Might be worth adding a "haxelib cache directory" for saving downloads.

You could also let the haxe executable check for a local ".haxelib/haxe/haxe.exe" and run that one instead if it exists, and thus have side-by-side installs.

Hugh

[Hugh]

While I'm at it, could we please add "haxelib directory lib" - like haxelib path, but returning the directory only part - no dependencies, no defines.

Hugh

[tondy]

my thoughts ...

for security reasons haxelib must check md5sum of downloaded zip and must not run downloaded from internet code. better compile in place on first run of library. neko is fast enough.

haxelib may have option only to download library. this will save bandwidth and help install on various computers at once. also public /wifispot/ internet cut big  downloads like openfl

haxelib may have option to install meta-package or pack like openfl  with proper versions of dependencies.

i do it manually right now. download & zip all necessary components of openfl  for example and copy and install on many computers.

haxelib may give freedom to developer to choice exe format of library. neko executable or native cpp if hxcpp can export makefile and compile with make  /if there is no neko/

haxelib /and every else haxetool/may contain nekovm with only std & regex ndll and rest of it functionality in standard neko language. like "nekotools boot". this will free hxcpp of neko dependency. if there is no neko use haxelib as neko

...