Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 02 07:12
    kevinresol commented #168
  • Nov 02 06:45
    back2dos commented #168
  • Oct 29 04:57
    kevinresol opened #168
  • Oct 08 12:09
    back2dos commented #167
  • Oct 06 21:10
    sebthom opened #167
  • Sep 28 17:07
    gene-pavlovsky opened #166
  • Sep 14 20:21
    MasterEric opened #72
  • Sep 11 14:00

    kevinresol on master

    Quote download location to work… Merge pull request #165 from se… (compare)

  • Sep 11 14:00
    kevinresol closed #165
  • Sep 11 14:00
    kevinresol closed #162
  • Sep 11 14:00
    kevinresol commented #165
  • Sep 11 13:59
    kevinresol commented #165
  • Sep 11 13:59
    kevinresol review_requested #165
  • Sep 02 10:51
    sebthom commented #165
  • Sep 02 10:51
    sebthom opened #165
  • Aug 31 17:02

    dependabot[bot] on npm_and_yarn

    (compare)

  • Aug 31 17:02
    dependabot[bot] closed #161
  • Aug 31 17:02
    dependabot[bot] commented #161
  • Aug 31 17:02
    dependabot[bot] labeled #164
  • Aug 31 17:02
    dependabot[bot] opened #164
Juraj Kirchheim
@back2dos
pretty sure it was better at some point ^^
Emugel
@emugel
If you work on a library libxyz, and its unit tests have a dependency, e.g. tink_unittest, you will have a libxyz/haxe_libraries/tink_unittest.hxml. Does that file implies a user of libxyz will also depend upon tink_unittest, or not?
Juraj Kirchheim
@back2dos
during a haxelib install haxelib.json is authoritative ... during a git(hub|lab) install, the haxe_libraries are, but if there's a haxelib.json only the dependencies resulting from that are taken
Emugel
@emugel
thanks:)
Kevin Leung
@kevinresol
Should we pack lix into a single executable to "get rid of the nodejs dependency"? https://www.npmjs.com/package/pkg
... for those nodephobics
Juraj Kirchheim
@back2dos
I don't mind ... but that actually creates a new distribution problem ^^
Peter Achberger
@Antriel
Could it run in eval? Then the only issue is Haxe version support. :D
On top of, you know, having to install Haxe before installing Lix. :(
Juraj Kirchheim
@back2dos
it'll have to be uploaded to brew, which AFAIK is a bit of a PITA, and then to choco and whatever Microsoft's package manager thingy is called and of course to all sorts of linux package managers
Rudy Ges
@kLabz
Eval is kinda slow, too. It has to handle compilation at runtime
Which can be noticeable with tink goodies
(also, "lix" is already taken in some(many?) linux package managers °°)
Kevin Leung
@kevinresol
can we "just" host the binary somewhere and instruct people to set up their $PATH manually
Juraj Kirchheim
@back2dos
I suppose ... I guess with github actions one could compile something for windows, linux and mac and add it as an artifact to the release or something
Kevin Leung
@kevinresol
ya iiuc the pkg library can compile the three platforms already
Juraj Kirchheim
@back2dos
ooooh, nice :)
Gabriel Hayes
@piboistudios
Seems like haxeshim is required to build hxcpp with lix. Which is also weird because you have to uninstall some of the files from one of the installs of either lix or shim to install both (because they both try to install the Haxe/haxelib/neko cmds etc)
Juraj Kirchheim
@back2dos
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 ;)
Gabriel Hayes
@piboistudios
@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
Ben
@benmerckx
Could this be considered for the next lix release? lix-pm/haxeshim#71
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
Juraj Kirchheim
@back2dos
it's available in 15.11
the CI via travisci.org is gone and when I try to add the repo on travisci.com, it's not there \o/
image.png
Ben
@benmerckx
Thanks :D It works for me now!
Gene Pavlovsky
@gene-pavlovsky
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?
Juraj Kirchheim
@back2dos
hmm ... do the download directives look right?
Gene Pavlovsky
@gene-pavlovsky
Which ones?
Gene Pavlovsky
@gene-pavlovsky
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)
Just for fun I also tried
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?
Juraj Kirchheim
@back2dos
lix download should not be resolving any dependencies
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
Gene Pavlovsky
@gene-pavlovsky

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?
Juraj Kirchheim
@back2dos
yeah, that'd make sense ... your other statement does not, though ^^
every project effectively cares about locking transitive dependencies ... this only becomes apparent when they're not locked :D
Gene Pavlovsky
@gene-pavlovsky
Yes but if we're locked to a particular version of lib A, that version will never change, doesn't that mean that by locking it to that version, we also automatically lock the transitive deps?
Anyway since you think the former makes sense, I made an issue on github