Fork me on GitHub
#lumo
<
2017-08-29
>
stbgz19:08:51

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

stbgz19:08:26

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

richiardiandrea19:08:37

yep you are right

dominicm19:08:57

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

dominicm19:08:05

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

stbgz19:08:31

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

stbgz19:08:20

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

richiardiandrea19:08:02

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

stbgz19:08:04

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

richiardiandrea19:08:28

in lumo yep that's true

stbgz19:08:02

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

stbgz19:08:42

and truly exploit the host(`js`) capabilities

stbgz19:08:13

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

stbgz19:08:21

it wasn't gwt though

stbgz19:08:28

I'll have to give that a try

richiardiandrea19:08:08

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

richiardiandrea19:08:54

I think JSweet does not provide that

dominicm19:08:55

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.

dominicm19:08:53

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

anmonteiro19:08:37

no it’s OK

anmonteiro19:08:39

reading the backlog

anmonteiro19:08:56

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

dominicm19:08:12

@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.

anmonteiro19:08:15

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

anmonteiro19:08:41

we actually have an issue open to support require from node_modules

dominicm19:08:58

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

anmonteiro19:08:59

the CLJS compiler just passes us namespace and path

anmonteiro19:08:06

we, as in, me

dominicm19:08:33

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

anmonteiro19:08:47

shouldn’t be too hard

anmonteiro19:08:02

the CLJS compiler passes us foo/bar

anmonteiro19:08:30

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

anmonteiro19:08:34

something like that

dominicm19:08:53

I should take a look at the code.

richiardiandrea19:08:04

@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

richiardiandrea19:08:18

so you could fetch that from anywhere basically

dominicm19:08:36

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

dominicm19:08:56

Must be a string. For websites.

dominicm19:08:54

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

richiardiandrea19:08:29

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

richiardiandrea19:08:53

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

richiardiandrea19:08:35

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

dominicm19:08:22

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

richiardiandrea19:08:06

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

richiardiandrea19:08:20

the same dep is already an npm dep

dominicm19:08:31

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

richiardiandrea19:08:48

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

dominicm20:08:59

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.

richiardiandrea20:08:03

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

richiardiandrea20:08:39

.node_modules/.bin/opencollective would work

anmonteiro20:08:12

no it wouldn’t

anmonteiro20:08:00

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

anmonteiro20:08:00

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

richiardiandrea20:08:09

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

anmonteiro20:08:13

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

anmonteiro20:08:20

I explained it to you yesterday

richiardiandrea20:08:28

yes just curious

anmonteiro20:08:29

that’s not Lumo’s package.json

richiardiandrea20:08:43

I was not the one asking 😄