This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (1)
- # beginners (6)
- # boot (25)
- # cider (30)
- # cljs-dev (50)
- # cljsrn (45)
- # clojure (93)
- # clojure-austin (5)
- # clojure-czech (1)
- # clojure-dev (21)
- # clojure-dusseldorf (29)
- # clojure-germany (2)
- # clojure-greece (117)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-russia (26)
- # clojure-serbia (10)
- # clojure-spec (123)
- # clojure-turkiye (1)
- # clojure-uk (27)
- # clojured (13)
- # clojurescript (57)
- # core-async (18)
- # cursive (13)
- # datomic (20)
- # defnpodcast (16)
- # emacs (8)
- # events (2)
- # figwheel (3)
- # instaparse (1)
- # jobs (3)
- # jobs-discuss (39)
- # klipse (9)
- # lumo (100)
- # mount (1)
- # numerical-computing (1)
- # off-topic (22)
- # om (34)
- # onyx (17)
- # pedestal (1)
- # perun (29)
- # re-frame (60)
- # reagent (16)
- # remote-jobs (8)
- # rethinkdb (6)
- # ring-swagger (19)
- # rum (1)
- # slack-help (1)
- # specter (3)
- # untangled (1)
- # yada (17)
I’m interested in using lumo for command line works. Got a few questions.
1. Is there any usage example that I can learn from out there?
2. If I want to interact with i/o (filesystem, network), should I shell out to use bash stuffs like
curl etc or should I use Node.js standard library like
3. To shell out, I should use something like
child_process (https://nodejs.org/api/child_process.html), right?
4. If I want to use npm libraries, how to I pack them into single easy-to-distribute file? Is that what calvin is for? Any calvin example I can learn from?
Have a question - I want to incorporate a lib - spec.cljs - into a CLJS project that I npm install, and invoke with Lumo. Anyone walked this path?
@anmonteiro did you get a chance to look into that dependency stuff? I'd like to write a cli tool which uses a nodejs dependency & not sure if I'll be able to.
@dominicm I did not and I should feel bad; I've had the tab open for ages. I'll ping you over the weekend
@anmonteiro It's okay, there is a workaround(https://github.com/juxt/mach/commit/62d2f5891233f0f1d088253840706239e92c61d2) anyway, but it's… ugly :stuck_out_tongue:
@anmonteiro I think I answered @jonpither's question in the JUXT slack :stuck_out_tongue:
It's exciting tech. @malcolmsparks has called 2017 "The year of Clojurescript on the server"
Lumo is awesome thus far @anmonteiro. I'm working also on https://github.com/juxt/roll which I'm using Lumo (via Mach) to drive. Haven't had as much fun for ages :slightly_smiling_face:
I have some scripts I've written for allowing admins to rotate passwords. Lumo has been a great choice
@anmonteiro look forward to seeing your updates. Right now we're using Roll, by doing this in a Machfile: #eval "node_modules/@juxt/roll/src/roll/core.cljs", to reuse NPM Cljs modules...
Right. I think the story around consuming libraries and modules is not thought out at all
I suppose we could attempt to read some kind of file (the equivalent to project.clj or build.boot) when starting up
@anmonteiro I feel like there's tension between how clojurescript currently expects to find dependencies & so on, & how node.js finds dependencies too.
I just feel like Lumo is in the equivalent state of calling Clojure via
java -cp ... clojure.main
@anmonteiro I'd be a little wary - perhaps for no good reason - about leaning on project.clj... right now we have a simple Machfile.edn that uses Lumo and it's nice to be out of the usual Lein/Boot JVM world. But hey, I've only just rocked up into this space
@anmonteiro I like your approach of leaving Lumo to be the
java -cp. I love that we have competing lein & boot.
yeah - I was more commenting on using project.clj. But I read your point more carefully, apologies: I suppose we could attempt to read some kind of file (the equivalent to project.clj or build.boot) when starting up
One think we wondering with Mach, is if there were a way to suck down cljs file dependencies from Git even :slightly_smiling_face:
that's more appropiate for Mach, but prob less so for Lumo where people will want NPM like repos with lots of interdependent cljs in
I suppose NPM can also do that because it reads package.json, which not every CLJS project will have
Could you make the rule that any dependent project must have the package.json to be supported?
I think it just needs some maturity. David Nolen has told me more than once that we can't get anything done in less than 2 years
@anmonteiro Am I grasping the entirety of the difficulties with:
- Node.js uses main for exposing apis mostly, with a
main being the only entrypoint to the project, which normally exposes the rest of the api, slightly unsuitable for cljs deps
- Clojurescript expects a list of folders in which to search for ns/file.clj based namespacing
- There's currently no way to start downloading jars from maven in node.js which could be used to form a "classpath"
Just from our hacky Mach prototype, I could envisage changing: #eval "node_modules/@juxt/roll/src/roll/core.cljs" to #eval ["@juxt/roll" :roll.core] where it a) looks for the roll npm module, b) uses the package.json to determine where the source is c) expects the file to be there based on the second arg
@dominicm: 1,2 and last can be summed up as heterogeneity of NPM vs traditional Maven repos, but you get it
Getting those deps could be solved with NPM and Huckleberry, but I don't know if Huckleberry is ready for usage yet
@dominicm: another problem to think about is how to declare a project's dependencies in a declarative, straightforward way (linking back to the project.clj talk)
I'm more than happy to open the Lumo wiki where we can distill these ideas in a design page
@anmonteiro I feel like a tool can be built on Huckleberry to fetch deps & run lumo with the classpath set. Which would make me think that Maven is the logical place to host code with cljs in it. There would still need to be node.js dependencies, but those can also be resolved by that same build tool using npm as a lib (or in a better world maybe yarn as a lib)
https://github.com/anmonteiro/lumo/pull/41 if something like this got merged, I think the boot equivalent wouldn't be too difficult…
unfortunately the work I’m gonna be landing this weekend kinda moves the project structure around a little bit so there’ll be some conflicts
I know @npeckman hasn’t had a lot of time to work on it, but it’ll be in Lumo in the near future
I've been working on it a lot this week, I'm currently struggling to get js zip to do what I want. Should have some time to really nail down my issues tomorrow and get it in a place you can evaluate soon!
@anmonteiro my big problem is this: when I get the zip object for the jar (an array of files) the files don't have the name field populated. Like when I get a file object off the array, I use the
toText () method to see the file, and the name field on the object exists as the documentation states, but the name field is just an empty object. Trying to list all the file names so this is a big barrier
I know the library is mature so I figure it's my fault, just trying to figure out what I'm doing wrong.
umo 1.1.0 ClojureScript 1.9.456 Docs: (doc function-name-here) Exit: Control+D or :cljs/quit or exit cljs.user=> (def JSZip (js/require "jszip")) #'cljs.user/JSZip cljs.user=> (def zip (.load (JSZip.) (fs.readFileSync "om.jar"))) #'cljs.user/zip cljs.user=> (.-name (.file zip "om/next.cljc")) "om/next.cljc" cljs.user=>
@npeckman you can also get all the files in the Zip, e.g.:
Lumo 1.1.0 ClojureScript 1.9.456 Docs: (doc function-name-here) Exit: Control+D or :cljs/quit or exit cljs.user=> (def JSZip (js/require "jszip")) #'cljs.user/JSZip cljs.user=> (def zip (.load (JSZip.) (fs.readFileSync "om.jar"))) #'cljs.user/zip cljs.user=> (js/Object.keys zip.files) #js ["META-INF/MANIFEST.MF" "META-INF/maven/org.omcljs/om/pom.xml" "META-INF/leiningen/org.omcljs/om/project.clj" "project.clj" "META-INF/leiningen/org.omcljs/om/README.md" "META-INF/" "META-INF/maven/" "META-INF/maven/org.omcljs/" "META-INF/maven/org.omcljs/om/" "META-INF/maven/org.omcljs/om/pom.properties" "data_readers.clj" "deps.cljs" "om/" "om/checksums.clj" "om/core.clj" "om/core.cljs" "om/dom.cljc" "om/dom.cljs" "om/externs.js" "om/impl.cljs" "om/next/" "om/next/cache.cljs" "om/next/impl/" "om/next/impl/parser.cljc" "om/next/protocols.cljc" "om/next/server.clj" "om/next.cljc" "om/tempid.cljc" "om/transit.cljc" "om/util.cljc"] cljs.user=>
@anmonteiro Thanks for the examples, think I'll be able to use them to hammer out my problems pretty quickly. I think the other big thing you needed were tests, I really hope to get that all to you before the weekend starts
@npeckman no rush, as I said there are some changes coming to the project structure and there’ll be conflicts :slightly_smiling_face:
I have some free time over the next few weeks, maybe I can do some hacking on lumo too,
@pesterhazy this would be good one to start https://github.com/anmonteiro/lumo/issues/74
this one seems easy too, and awesome for UX https://github.com/anmonteiro/lumo/issues/62
@jonpither I put some work to rsolve the deps gathering issue you can take a look at https://github.com/eginez/calvin
@dominicm the calvin project I have been working on address "There's currently no way to start downloading jars from maven in node.js which could be used to form a “classpath””, in fact calvin is already creating a classpath for you and launching the repl with such classpath, granted is reading project.clj but that doesn’t need to be the case
@npeckman I had an issue like that last week when I was trying to work with JZip I’ll commit my code to github a pass you the link, I think you might find it useful