(including haxe)

Maybe that was bc most Linux folks were talking it up at haxesummit

its not a linux thing

I think even juraj is a windows user? not totally sure though

yeah, he is

its irrelivent

lix is not system restricted

so... why isnt lix "haxelib"?

polotics? nonsense? Its a better system... why should i "opt in"?... ... ... Nick?

I think there's two main obstacles

- lix currently needs haxeshim, which is basically a hack. Haxe would need to be able to resolve libraries from the haxe_libraries folder instead of having a hardcoded dependency on Haxelib (calling

haxelib path

to resolve libs)

right

Having everything switch to lix sounds swell (I think, having never used it but thinking the world of juraj). However, what can be done in the next week or a few? I dare say an acceptable improvement with regards to feedback in haxelib may be quicker and not harmful to possibly eventually switching to lix.

makes sense

- and also, lix currently depends on Node APIs, if it were to be bundled with Haxe that seems problematic.. potentially solved by the new Haxe sys APIs that are in the works though (then lix could in theory run on any Haxe sys target)

you mean file access?

I think https is one of the things it uses, probably more

right

sockets too I suppose for haxeshim

(to emulate --connect)

ssl is non existant in the standard libs

@bright-yak-48460 as knows very well

Sure do. Have to patch it every time I update and rebuild static lime.

yawn

lix is based on the concept of node|npm if I am not mistaken and it has cool features but git submodules are still a better solution. We avoid the npm install debacle and users should know how to install haxe and versioning with vscode is easy, just "haxe.executable": path/to/version/of/haxe. We could also go the kha way and have git bins of haxe and the vm's as submodules.The latter is the workflow I prefer as it's based on versionning with git which we already do for code so everyone should understand this and we remove learning a new unneeded tool.

I say unneeded in the sense that git can do the work that it does.

using submodules for all dependencies of a big project can get quite heavy

both in terms of size and performance (at least with some git GUIs I've used)

there isn't really a need to have the whole history of your dependencies if you don't intend to modify them

I only use git guis to add-commit-push; cloning from command-line is smooth. Cloning a project with a lot of submodules can impact performance of git guis yes. Having the whole history let's you revert to an older version when the dependencies maintainer makes a mistake(we are humans so...) which can avoid stress when close to a release/milestone date