Clojurians Log v2

@richiardiandrea @dominicm I think I am seeing refereces to aether in tools-dep https://github.com/clojure/tools.deps.alpha/blob/4b3a3cb82950928ee2d7887fbaadd1c68f067834/src/main/clojure/clojure/tools/deps/alpha/providers/maven.clj#L16

which is unfortunate because I was hopping for a clj only dep resolution implementation

as far as I can tell huckleberry is the only dep resolultion implementation in clj

yep you are right

@stbgz resolution was a non goal. Likely because of all the stigma around implementing checksums and signatures.

I see

The interest is generating class paths as far as I can tell.

right!

you know the whole classpath thing for cljs makes little sense to me... why do we need them in cljs

I think we ought to rethink the whole classpath thing for cljs

in cljs-JVM there is still a classpath, unless things change in the future and we take an npm approach for installing compiled js from cljs in node_modules

I know in lumo we can dynamically inject new dependencies at runtime

in lumo yep that's true

@richiardiandrea agreed I think we should be pushing the boundaries in that regard

and truly exploit the host(`js`) capabilities

also I don't if I mentioned this before I tried running aether through one of the java->js convertes and it did not work for some fundamental reason. that I now forgot since I did it several weeks ago

it wasn't gwt though

I'll have to give that a try

@stbgz from what I understood there should be some sort of node.js virtual machine for the java calls...for instance for IO

like http://plasma-umass.github.io/doppio-demo/

I think JSweet does not provide that

I think clojurescript has entwined it's fate to that of classpaths. The model it uses for consuming cljs code is quite tied to it. I'm sure @anmonteiro could speak to how true this is/isn't, particularly given the latest work on Google closure + node modules.

uh

Sorry, didn't mean to put you on the spot :)

no it’s OK

reading the backlog

self-hosted may not be that tied to the concept of classpaths

@stbgz if you're really determined, Alex suggested to me that most of maven is pointless inheritance and interfaces. And that the meat of it isn't huge. It might turn out to be simpler than it appears.

theoretically it can load from anywhere, even from a remote connection (that’s what http://clojurescript.io does)

we actually have an issue open to support require from node_modules

@anmonteiro that's extremely intriguing. Which "we" is that?

the CLJS compiler just passes us namespace and path

we, as in, me

😜

in Lumo

Are you thinking of something centred on package.json reading?

maybe

shouldn’t be too hard

the CLJS compiler passes us foo/bar

so that should be node_modules/foo/pkgjsonmain/foo/bar.cljs

something like that

brb

I should take a look at the code.

@dominicm to expand a bit on that, self-host cljs allows you to pass a load-fn function that has to return the required code

so you could fetch that from anywhere basically

When you say it returns the code, is it as a string, or a path?

Must be a string. For websites.

yep: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L74

Hmm. Is there a funky way to set that in lumo? Such that I might experiment with the idea of loading from node modules?

sorry for the wrong link, correct -> https://github.com/anmonteiro/lumo/blob/master/src/cljs/snapshot/lumo/repl.cljs#L301

the problem is that most cljs packages at the moment don't pack files and publish to npm

still, it would be a very good thing if they did

for cljsjs, a boot task could produce and publish to npm together with Clojars

Yeah, no way to get rid of maven at this point I think. I'm curious to know how the .net clj does dependencies

uhm actually I don't think packing cljsjs would make too much sense except for providing externs

the same dep is already an npm dep

Cljsjs really doesn't make sense in lumo, nope 😂

lumo-compatible packages would declare their compatibility by publishing on npm (like many already do)

On my phone right now, but... https://github.com/anmonteiro/lumo/issues/241 This should work as it is. Npm supposedly has that directory on the path whilst it's running.

@dominicm uhm no it doesn't 😄 node does not add .node_modules/.bin in your PATH

.node_modules/.bin/opencollective would work

no it wouldn’t

scripts in package.json actually sees stuff in ./node_modules/.bin

https://docs.npmjs.com/misc/scripts#path

the fact that you can’t execute opencollective is because it’s listed in devDependencies, not dependencies

uhm...yes you folks seem right...but I get an error...it must be something else then

you shouldn’t be installing node from github:anmonteiro/lumo anyway

ah cool

I explained it to you yesterday

that is why

yes just curious

that’s not Lumo’s package.json

I was not the one asking 😄