Fork me on GitHub
#boot
<
2015-07-09
>
martinklepsch01:07:26

@micha: @crisptrutski re by-path — isnt there (:tree fileset) or something? That's what I ended up using. A more public API like thing would probably good though :)

mitchelkuijpers08:07:50

lol wrong window 😛

andrewmcveigh08:07:18

don’t wanna type something sensitive in there… like I have

micha12:07:21

martinklepsch: yeah having an API in boot.core is probably a good idea, although we haven't really nailed down exactly what the public api of boot is

micha12:07:37

but definitely boot.core and boot.pod would be part of that

juhoteperi12:07:48

@micha: Do you have opinion on what boot-cljs options should be task options and what should be set from .cljs.edn? I'm thinking main ns, init-fns and (implicitly) docroot are set in cljs.edn and rest from task options (optimizations, source-map, compiler-options).

micha12:07:13

deraen: agree

micha12:07:20

deraen: isn't that how it is currently?

juhoteperi12:07:41

@micha: I'm not sure, I see some mentions that compiler options could be set from cljs.edn

micha12:07:53

yes we should support that i think

micha12:07:08

i.e. anything you can do from the command line should be able to be done in cljs.edn

micha12:07:14

but command line overrides

juhoteperi12:07:20

I'm not sure, I don't think it's reasonable to change compiler options during autobuild

micha12:07:48

the cljs compiler task could run differnt compilers in pods

juhoteperi12:07:22

First I though options could be merged but I now think it would be simpler to define where different options must be set

juhoteperi12:07:28

One cljs task = one compiler

micha12:07:37

agree yes

micha12:07:58

we can make a parallel fanout and merge task too

micha12:07:06

if we really want to do multiple builds

micha12:07:18

(comp (cljx) (garden) (parallel-tasks (cljs ...) (cljs ...)))

micha12:07:23

or something

juhoteperi12:07:41

Yeah that could be useful

juhoteperi12:07:17

Also, would be easy to use lazy-graph to order tasks automatically (user would write the task dependencies)

micha12:07:43

haha that's where i become skeptical simple_smile

micha12:07:54

but yes we could totally do it

juhoteperi12:07:05

Well, that should be something which should be posssible to do in external lib

micha12:07:34

some combination of pipeline + DAG might be the sweet spot

juhoteperi12:07:36

I wonder if there is any reason to create the cljs.edn file if it doesn't exist

micha12:07:44

the DAG flattens to a pipeline anyway, and the fileset will help lessen the coupling

micha12:07:02

yes it's to support other tools that use cljs.edn

micha12:07:13

to know things about the application

juhoteperi12:07:27

But it's creating the file in pre-wrap so other tasks wont see it?

micha12:07:56

it should do it in the constructor perhaps

juhoteperi12:07:10

it needs fileset

micha12:07:11

oh nm i t cant

micha12:07:52

i think we should add a lot more metadata to the compiled js files in the fileset

micha12:07:10

like the analysis info like cljs namespace, requires, provides, etc

micha12:07:25

that info will be really useful for other tasks, like cljs-test for instance

juhoteperi12:07:43

Maybe, but I also want to minimize anything which could be changed by changes in Cljs

micha12:07:01

yeah i hear that

juhoteperi12:07:22

currently boot-cljs only using cljs.build.api, cljs.env (which should be okay though it isn't a api ns) and cljs.analyzer which might break anytime

juhoteperi12:07:53

and the ordering stuff is reading compiler env directly which is bad

micha12:07:10

i don't think we need to chase the latest version of cljs, do we?

micha12:07:38

can't we keep our own sanity by just sticking to something that works until there is a clear path forward?

micha12:07:57

i mean i'm still using a version of cljs from before clojure/west

micha12:07:11

works fine for me

juhoteperi12:07:31

Well, I'll be using latest cljs but yeah I'm okay using something that works until there is something clearly better

juhoteperi12:07:56

I did check the ordering stuff yesterday and I didn't see way to currently do the same using public api

micha12:07:21

we could make our own cljs compiler api

juhoteperi12:07:28

So once boot-cljs is otherwise cleaned I might take another look at that and see what it would require in cljs end to make it work

micha12:07:29

and make that fixed and stable

juhoteperi12:07:38

or we could just improve upstream cljs

micha12:07:40

then we need only write glue for each version of cljs compiler

micha12:07:56

right that would be the template for the upstream proposal

micha12:07:30

but like a proposal that hasn't been in production and proven to be useful will waste a lot of our time in discussion

juhoteperi12:07:42

Yeah it could work both ways, the library would mimick cljs api for old cljs versions and work as template to find new api functions

juhoteperi12:07:59

which is what bhaumans clojurescript-build does, I think

micha12:07:14

yeah that also does the macro reloading

micha12:07:22

which is something we could use i think

juhoteperi12:07:26

At least many functions cljs api seemed to be directly copied from there

juhoteperi12:07:39

there is some functions for macro reloading in public api

juhoteperi12:07:08

or not for reloading, but for checking if there are any cljs namespaces which depend on macros on a clj ns

juhoteperi12:07:22

and then you can do the actual reloading how ever you want

micha12:07:38

it would be nice if the cljs compiler would have persisted state

micha12:07:47

then we could just make a pod pool and not worry about it

micha12:07:42

but hot reload of namespaces works most of the time

juhoteperi12:07:30

back to cljs.edn, would it be reasonable to remove default cljs.edn and warn user that other tasks can't add their stuff it cljs.edn doesn't exist?

juhoteperi12:07:42

as it, afaik, doesn't even work currently

micha12:07:51

what's broken?

juhoteperi12:07:14

I don't see how the other tasks could see the default cljs.edn

micha12:07:50

tasks after cljs in the pipeline surely do

micha12:07:00

but for tasks before cljs though

micha12:07:46

the cljs reload and stuff do work without cljs.edn

micha12:07:58

maybe we don't need to generate it

juhoteperi12:07:06

But tasks after cljs in the pipeline are run after cljs compilation is done

micha12:07:20

sure but they might need to know about the application

micha12:07:26

like what the entry point is

micha12:07:37

that's useful info for tasks to have

micha12:07:52

also i think maybe we do need to generate it

micha12:07:00

the way it works with cljs reload for example

micha12:07:17

i think cljs creates a cljs.edn with :requires for all project namespaces

micha12:07:28

that would include the one created by reload for instance

micha12:07:47

so if we didn't generate that namespace we'd break reload etc

micha12:07:27

what about a separate task to generate cljs.edn?

micha12:07:15

boot cljs-app --provides foo.bar --requires asdf.qwer --requires xzcv.poiu -- cljs

juhoteperi12:07:38

I'm thinking cljs task would have :id option which would select the cljs.edn file

micha12:07:34

perhaps yeah

juhoteperi14:07:18

@micha: Perhaps it would be simplest if cljs task always wrote .cljs.edn, in addition to properties already in file, it could write compiler options etc. there for debugging and for other tasks

juhoteperi14:07:54

Though is there a good reason to use file instead of just metadata on fileset?

juhoteperi14:07:00

Except for initial data

micha14:07:08

yeah i really like the idea of haivng a file that describes the parameters of the build in some abstract way

micha14:07:21

like a schematic of the application in a way

micha14:07:29

which tools can use to do things intelligently

micha14:07:48

but without coupling between specific tasks

juhoteperi14:07:09

Should there be an API for other tools which need to read/manipulate cljs.edn or should boot-cljs presume that others know how to do that manually?

micha14:07:21

good question

micha14:07:35

perhaps an api separate from boot-cljs

micha14:07:51

also i like the idea of using fileset metadata i think

juhoteperi14:07:06

or separate ns?

micha14:07:13

if filesystem meta can serve the purpose that would be a really elegant solution i think

juhoteperi14:07:16

the plugin after all doesn't have dependencies

micha14:07:45

a separate thing would i think decouple dependency issues

micha14:07:58

like separate the application spec from the weirdness of cljs

juhoteperi14:07:23

I doubt there is any dependency issues if there is separate ns (adzerk.boot-cljs.api) which would probably depend only on boot.core

micha14:07:38

and the cljs compiler task is a good place to have it

juhoteperi14:07:16

Pff, I would like to finish perun/endophile/pegdown changes but Pegdown developer doesn't seem to be active :S

juhoteperi15:07:13

(https://en.wiktionary.org/wiki/pff#English I did check that pff is valid interjection)

micha15:07:21

it's a great one

gtrak18:07:40

was able to get a script working easily, but noticed dosh and sh don't allow for passthrough of opts to conch. seems like it'd be nice to be able to pass the stdin reader into each process for interactive stuff.

alandipert18:07:31

iirc there's a dynamic var you could use to achieve this

alandipert18:07:30

oh nvm, that's *sh-dir*

alandipert18:07:24

but anyways, you could drive conch more directly through boot.from.me.raynes.conch, the vendored version of it

alandipert18:07:39

using the sh/dosh implementations as a starting point

alandipert18:07:52

would that help?

gtrak18:07:14

right, i could totally do it that way, was considering using conch directly as a dep

micha18:07:43

gtrak: would adding a dynamic var help?

micha18:07:56

or some other mechanism?

gtrak18:07:56

possibly, i haven't even used it in anger yet, so I can't say i'm fully informed, but this was the first thing i tried to do with boot and the first issue i hit with it.

gtrak18:07:41

it seems like being able to specify opts to conch would give all the extensibility you'd want.

gtrak18:07:16

and a dynamic var is fine for that, since it's using futures or synchronous and those values get conveyed.

micha18:07:47

gtrak: PR gratefully accepted, or if you make an issue describing how it would work we can make it happen

gtrak18:07:56

cool cool

micha18:07:31

i'd like to see how to correctly handle interactive shell-out, in any case simple_smile

gtrak18:07:16

Just launching ffmpeg recursively to reencode all the euroclojure vids at 1.7x speed simple_smile. it prompts for overwriting files.