Should we pack lix into a single executable to "get rid of the nodejs dependency"? https://www.npmjs.com/package/pkg
... for those nodephobics
On top of, you know, having to install Haxe before installing Lix. :(
Which can be noticeable with tink goodies
(also, "lix" is already taken in some(many?) linux package managers °°)
as the friendly red block over at npm indicates haxeshim is deprecated (and now exists only as a haxe library that is compiled into lix)
if some particular thing doesn't work with lix, please open an issue, with as many details as possible on how to repro ;)
@back2dos I know. But Lix (latest) failed to compile hxcpp without haxeshim installed as well (it could compile other targets but for hxcpp it was complaining about haxeshim module). I had tried manually deleting the files out of my global npm and installing Lix fresh but it didn't resolve the issue
Ultimately what I had to do was:
Completely uninstall lix (and by this I mean I ran npm uninstall and also deleted the cmds/sh/scripts for Haxe out of npm folder), install haxeshim, delete the cmds/sh/scripts again (Lix tries to install these as well, because as you said it includes haxeshim), then install lix, and it built
Oh I just now saw your second message. I'll open an issue
Use case for me: I'd like to update https://github.com/benmerckx/watch to have a runnable main to be able to do
lix watch build.hxml
the CI via travisci.org is gone and when I try to add the repo on travisci.com, it's not there \o/
Hey guys, I have a question about --haxelib-url.
In our project, we are getting most of the dependencies from a private haxelib repo.
They were installed using lix install --haxelib-url ...
But some libs are installed from github.
When running lix download, the subdeps of those libs are downloaded from the public haxelib repo, which is undesirable in our case.
Is there some way to tell lix to use the private haxelib url in this case?
Perhaps this option can apply to lix download?
In our project, we are getting most of the dependencies from a private haxelib repo.
They were installed using lix install --haxelib-url ...
But some libs are installed from github.
When running lix download, the subdeps of those libs are downloaded from the public haxelib repo, which is undesirable in our case.
Is there some way to tell lix to use the private haxelib url in this case?
Perhaps this option can apply to lix download?
lix install gh:gene-pavlovsky/haxe-checkstyle#4198dfcebdb6d08d41805e60e9a145b2c9949aed
results in:
https://gist.github.com/gene-pavlovsky/4fa19974e837bf7243e96fc5144aa3ad
results in:
https://gist.github.com/gene-pavlovsky/4fa19974e837bf7243e96fc5144aa3ad
Running lix download later downloads the lib from github, and (I guess predictably) the sub-dependencies from the public haxelib server
I tried
lix install --haxelib-url http://host:port gh:gene-pavlovsky/haxe-checkstyle#4198dfcebdb6d08d41805e60e9a145b2c9949aed
And the hxml file generated is the same as without the option (perhaps predictably)
lix install --haxelib-url http://host:port gh:gene-pavlovsky/haxe-checkstyle#4198dfcebdb6d08d41805e60e9a145b2c9949aed
And the hxml file generated is the same as without the option (perhaps predictably)
Just for fun I also tried
lix download --haxelib-url ...
And it works same as
lix download
Again, I guess predictably
lix download --haxelib-url ...
And it works same as
lix download
Again, I guess predictably
Any solution for this conundrum, besides modifying the dependencies of the lib on github, or packaging that lib and deploying it to the local haxelib server?
only lix install deals with dependencies
so it's when installing checkstyle, that its dependencies are specified in their respective hxmls
you can, for example, reinstall those manually from your haxelib server
you can, for example, reinstall those manually from your haxelib server
This idea crossed my mind, although it's a less than ideal solution. The project itself doesn't really care about these sub-dependencies, so it would be nicer if they don't have to be in the project's haxe_libraries.
I think that logically, when one installs a lib from github, with --haxelib-url specified, the haxelib url should be still honored / stored in the lib's hxml file, so that if the lib's sub-dependencies come from haxelib, they would come from the specified one. What do you think?
every project effectively cares about locking transitive dependencies ... this only becomes apparent when they're not locked :D
Anyway since you think the former makes sense, I made an issue on github