New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lumo: init at 1.9.0-alpha #44076
lumo: init at 1.9.0-alpha #44076
Conversation
be73af9
to
1b83e02
Compare
@GrahamcOfBorg build lumo |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: lumo Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: lumo Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: lumo Partial log (click to expand)
|
I don't really know enough to know if this is good. It seems like a lot of custom setup and building is going on here. Maybe this is okay given that this is a compiler. I'll squash and merge this in soon if no one objects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get:
Archive: /nix/store/hz99ddmp9v7ka3dm9p4b9cp7yv7wkfxk-org_clojure_test_check-0.10.0-alpha2.jar
inflating: ./target/META-INF/MANIFEST.MF
creating: ./target/clojure/test/
creating: ./target/clojure/test/check/
creating: ./target/clojure/test/check/random/
creating: ./target/clojure/test/check/random/longs/
inflating: ./target/clojure/test/check.cljc
inflating: ./target/clojure/test/check/results.cljc
inflating: ./target/clojure/test/check/clojure_test.cljc
inflating: ./target/clojure/test/check/impl.cljc
inflating: ./target/clojure/test/check/properties.cljc
inflating: ./target/clojure/test/check/generators.cljc
inflating: ./target/clojure/test/check/random.clj
inflating: ./target/clojure/test/check/random/doubles.cljs
inflating: ./target/clojure/test/check/random/longs/bit_count_impl.cljs
inflating: ./target/clojure/test/check/random/longs.cljs
inflating: ./target/clojure/test/check/random.cljs
inflating: ./target/clojure/test/check/rose_tree.cljc
creating: ./target/META-INF/maven/org.clojure/test.check/
inflating: ./target/META-INF/maven/org.clojure/test.check/pom.xml
inflating: ./target/META-INF/maven/org.clojure/test.check/pom.properties
java.io.FileInputStream
#'user/write-transit-json
#'user/process-caches
/build/lumo-1.9.0-alpha/scripts/bundle.js:83
);
^
SyntaxError: Unexpected token )
at createScript (vm.js:56:10)
at Object.runInThisContext (vm.js:97:10)
at Module._compile (module.js:549:28)
at Object.Module._extensions..js (module.js:586:10)
at Module.load (module.js:494:32)
at tryModuleLoad (module.js:453:12)
at Function.Module._load (module.js:445:3)
at Module.runMain (module.js:611:10)
at run (bootstrap_node.js:387:7)
at startup (bootstrap_node.js:153:9)
builder for '/nix/store/34mkwq4m76nqaavnxx21z258zh5qn9r3-lumo-1.9.0-alpha.drv' failed with exit code 1
error: build of '/nix/store/34mkwq4m76nqaavnxx21z258zh5qn9r3-lumo-1.9.0-alpha.drv' failed
Sorry for the delay, I looked at this syntax error and it seems to be in the package itself https://github.com/anmonteiro/lumo/blob/1.9.0-alpha/scripts/bundle.js#L76-L84 there's a comma after the array.push call, which shouldn't be there, but I'm surprised that js forgiveness isn't so forgiving on your computer. Are you using node11? Should I fix this with sed? |
@hlolli, it probably makes more sense to use a patch. |
@yegortimoshenko saga continues, I bumped to 1.9.0 release, added patch for that comma thingy plus some fs promises that were only recently added in node version 10.7.0 (and are experimental). It compiles in nodejs 8 (the current nodejs version on nixpkgs) and all later versions, if you are testing this on a node version lower than 8, then I can only cross fingers that it will compile and run (are we supposed to support so old node versions anyway?). I had to prevent strip, this is an issue from the binary bundler and npm package |
@GrahamcOfBorg build lumo |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: lumo Partial log (click to expand)
|
Failure on x86_64-darwin (full log) Attempted: lumo Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: lumo Partial log (click to expand)
|
Or inject override in
|
I thought it wasn't allowed :), I think injecting it in callPackage makes sense. But it does work for both nodejs 8 and 10, I used That darwin build failed, the platforms = all was a mistake. If I have darwin with nix, I'll try to debug it later, so I'll change it, targeting linux only for now. So 3 things, I remove the patch, remove platform =all to linux and add the inject override. Squash and push. |
@infinisil done #50181 |
@hlolli I said two separate commits. PR's are annoying for that because then one depends on the other :) |
ah I see :) should be quick fix, 1min... |
ok I wasn't quick enough to close my PR :) it got merged. uh.. it should be fine then? @infinisil |
@GrahamcOfBorg build lumo |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: lumo Partial log (click to expand)
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: lumo Partial log (click to expand)
|
@@ -0,0 +1,110 @@ | |||
{ | |||
"name": "lumo-cljs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to add lumo-cljs
to pkgs/development/node-packages/node-packages-v8.json
.
Then we can share its dependencies with other node packages. 17k of dependencies is not acceptable for a single package. Git and nix do not like large files like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be a good idea. Don't know if this has changed, but there was such a lack of example useage of yarn2nix in nixpkgs that I felt a bit on my own. That said, if you read the other 3 PR for lumo (lumo = lumo-cljs (lumo was already reserved on npm)), then all that the npm-module does is downloading a binary file from github, a binary file that can not run on nixos no matter the amount of binary hacking. So the npm module itself is useless in terms of lumo in Nixos. But I guess that the npm dependencies to build lumo could be shared, that would mean that I would need to make 40 nix derivations before we can build lumo in nixpkgs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing, if two nix epression want to fetch the same url with the same sha sum, isn't that resource shared in nix-store, even tough the reference is seperate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also not 17k, it's 1038 fetchurl's to yarn registry. It's a whole lot I admit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not just about sharing the source (which is the case) but also evaluation time and channel size (each user would then need to store an 1mb extra of expressions just for a single package).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you the package would be included in nodePackages
can its dependencies not also used from there?
$ nix repl '<nixpkgs>'
nixpkgs> :b nodePackages.eslint
> "${nodePackages.eslint}"
/nix/store/7sk5kg95rdy25rjdxvknxl3rmkgjcxxg-node-eslint-5.8.0
> ls -la /nix/store/7sk5kg95rdy25rjdxvknxl3rmkgjcxxg-node-eslint-5.8.0/lib/node_modules/eslint/node_modules/
We could even delete unusable binaries from the package itself by adding an override.
Many of the dependencies listed here are already include in node-packages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the package is in node dependencies, I will have to test if the build tool (yarn/npm) will no just try to make lockfile, or fetch dep graph fro the mirror. I had this problem with npm2nix, that I couldn't stop it from making http requests. The thing that I worry about too, is that I would only be adding lumo-cljs to nix's node-packages for its build dependencies but not runtime, and the readme in pkgs/development/node-packages
said it only wants top-level packages. Lumo isn't a traditional package, npm is part of the process of building it, it serves more as a way to install the binary globaly than as node module. You are right that I can diminsih the size quite a bit, it's now total for 6 files 633.6kb and I made a comment about this size in my PR message. I could try to make this smaller. And I can try adding lumo-cljs as non top-level npm module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Libraries should only be added to the package set if there is a non-NPM package that requires it." so in the Lumo's case it should be fine :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do the same already for meguca.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you look over my PR now, this looks quite strange, the version name actually takes relative path, and that's appended to the nodePackages attribute name. But it works fine like this (hopefully GrahamcOfBorg aggrees).
Success on x86_64-linux (full log) Attempted: lumo Partial log (click to expand)
|
Awesome, thanks :) |
😰 I made changes to @Mic92's review, from which time GrahamcOfBorg didn't run |
@hlolli I tested it locally, the build and everything works fine :) (GrahamcOfBorg just build the derivation anyways) |
This broke the tarball job on hydra https://hydra.nixos.org/build/83951478/nixlog/1 due to the import of |
"http://oss.sonatype.org/content/repositories/public/" | ||
"http://repo.typesafe.com/typesafe/releases/" | ||
]; | ||
pkgs = import <nixpkgs> {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh yeah, this is the problem here. Does clj2nix have a way to not use import <nixpkgs> {}
and instead take an argument? Otherwise this needs to be fixed manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh shit, this is my first nixos plugin, so it's no surprise I did something wrong. Yes, I'll find a solution, inherit pkgs or worst case, pass fetchMavenArtifact as argument. Can this wait 24h?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe I do this after eating (2H)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could just add pkgs:
at the top of this file, remove line 10 instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, stuff breaks all the time, I'm just glad @cocreature noticed it this early :)
''; | ||
|
||
|
||
cljdeps = import ./deps.nix; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then change this to cljdeps = import ./deps.nix pkgs;
while getting pkgs
by adding it to the argument list at the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea, I do that!
@GrahamcOfBorg build lumo (A bit late, but I want to confirm whether it has issues with the |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: lumo Partial log (click to expand)
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: lumo Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: lumo Partial log (click to expand)
|
Motivation for this change
This would be the 4th attempt to get lumo into nixpkgs, the other 3 being
#33691
#25770
#38619
This is built completely from source. Jar dependencies are fetched from deps.nix, generated by deps.edn via clj2nix. Node modules are fetched via yarn2nix, other projects using yarn2nix also put the yarn.lock and package.json into the nixpkgs tree, despite the lockfile size can get pretty big (here 200k).
Lumo is built just like it is built with boot. Boot turned out to be unable to be used in offline mode, because it ignores java classpaths. Therefore I used the clojure cli tool where I needed to call clojure to build clojurescript sources.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)