Just to check that I correctly understood the concepts :
- it's upfront, in the task itself, that the decision of whether what the
task produces is of type "input" or "output".
- flagging part of its output as "input" type is a way to declare to boot
that the files there MUST be processed further, at some point, or else
there's an error somewhere?
- the granularity of input / output files is the directory (it's at the
directory level that content is flagged as "input" or "output"). Is it
recursive (I guess so), for subdirectories of the tagged directory?
- add-src somehow pipelines some files tagged as "input" in the input of
the task as "output" for the rest of the pipeline, thus ensuring those
files will reach the target/ directory (and they may or may not be
subsequently modified on their way to target/, this is somewhat an
orthogonal concern). Right?
Some remarks (I know that Names Are Hard):
- :src-paths and :rsc-paths are already difficult to distinguish when one
does not have diseases related to ordering of letters. Maybe falling back
to longer names could fix this: :source-paths and :resource-paths
Cheers,
--
Laurent
2014-11-07 16:59 GMT+01:00 Micha Niskin <micha.nis...@gmail.com>:
> Henrik, can you make a github repo with what you were trying to do in your
> second question? It would help to be able to see your whole setup.
>
> The add-src task is perhaps confusingly named (Names Are Hard). Its
> purpose is to shuffle files around in the file set, moving files that would
> normally be considered “source” files into the stream of artifacts that end
> up being packaged. It’s roughly equivalent to setting Leiningen’s
> :omit-source key to false (but it’s a composable task, not a global
> setting).
>
> I’ll try to explain how this works. To model all the filesystem side
> effects that building software entails we must establish some types of
> files, aligned along some basis of user intent. We ended up with two
> categories: input and output files (again, Names Are Hard, so please bear
> with me).
>
> -
>
> *input* – files that MUST be processed further before being packaged
> or emitted to the project target directory (eg. Java source files, CLJS
> source files, etc.)
> -
>
> *output* – files that MAY be processed further, but can be included in
> the packaged artifact or emitted to the project target directory (eg.
> compiled JavaScript, Java bytecode, etc.). Note that this also includes
> files that might pass through the build system completely unmolested to end
> up in the final result, like your index.html file for instance. These
> are also called “resources” in Java parlance, I believe.
>
> A major concept in boot has that the output of a task is always part of
> the input of subsequent tasks. Tasks shouldn’t know or care what is to be
> done to the artifacts they emit; they shouldn’t know or care who or what
> might be further processing them. Thus, both input and output files are on
> the classpath. This means that both types serve as input for tasks, which
> is, I admit, somewhat confusing.
>
> When you set up your environment in boot you use the :src-paths and
> :rsc-paths arguments to set-env!. The :src-paths denote *input* dirs,
> :rsc-paths *output* dirs.
>
> This brings us to tempdirs. Tasks that emit files do so in anonymous temp
> dirs they obtain from boot core. These temp dirs come in a few flavors, but
> there are two main classes of temp dir a task may create: *input* or
> *output*, naturally. The choice is left to the task writer, who decides
> based on his intent. For example, the cljs-repl task emits a CLJS
> namespace containing the websocket connection code the client needs to run
> to connect to the REPL server. This namespace is emitted into an *input*
> type temp dir. Thus the CLJS namespace is compiled into the application JS
> file, but the CLJS source does not appear in the app webroot.
>
> Finally, we arrive at add-src. This task creates a temp dir of the
> *output* type. It then obtains a list of *input* type files from boot
> core and moves them into this dir. Then when the jar task for example
> runs later in the pipeline, these source files will be included in the jar.
>
> I’m not sure how clear this is, I’m trying to figure out the best way to
> explain this stuff and this is one of the first iterations :)
>
>
> --
> Micha Niskin
>
> On Fri, Nov 7, 2014 at 6:46 AM, Henrik Eneroth <henrik.ener...@gmail.com>
> wrote:
>
>> Agreed, because it seems like a good tool. :-)
>>
>>
>> On that vein; what's the syntax for add-src?
>>
>> I'm trying to include helper.cljs in the project, a file with a bunch of
>> convenience functions that I use. However, I get the following error:
>>
>> << stopping Jetty... >> clojure.lang.ExceptionInfo:
>> clojure.lang.ExceptionInfo: Could not locate helpers__init.class or
>> helpers.clj on classpath: at line 1 {:tag :cljs/analysis-error, :file
>> nil, :line 1, :column 1}
>>
>> It seems enamoured with the idea that the file should end with ".clj".
>> I'm guessing that boot has to be told of the existence of the file, but I'm
>> not sure how to do this. For the purposes of this experiment, the namespace
>> of helpers.cljs is simply (ns helpers).
>>
>>
>> On Friday, November 7, 2014 12:01:14 PM UTC+1, Laurent PETIT wrote:
>>>
>>> Really looking forward to a couple more blog posts:
>>>
>>> - an instructive / provocative one which could be named after "how to
>>> replace leiningen with boot 2". Would be very practical, showing how all
>>> major usecases done with lein translate to boot.
>>> - an tutorial / documenting one on how to write new task and be good
>>> citizens of boot (what to do, what not to do, and then how)
>>>
>>> :-)
>>>
>>>
>>> 2014-11-07 10:16 GMT+01:00 Henrik Eneroth <henrik....@gmail.com>:
>>>
>>>> I tried now, just running boot -u, and it worked perfectly. It's was
>>>> probably some caching thing with Clojars. Currently at pre21
>>>>
>>>> Now the command runs without errors, but it also doesn't seem to do all
>>>> that much.
>>>>
>>>> Running
>>>> > boot -d reagent/reagent:0.4.3
>>>> gives the exact same output as running
>>>> > boot -h
>>>> currently.
>>>>
>>>>
>>>>
>>>> On Friday, November 7, 2014 12:18:41 AM UTC+1, Micha Niskin wrote:
>>>>>
>>>>> It looks like Clojars is doing what I thought it would do:
>>>>> https://clojars.org/repo/boot/boot/maven-metadata.xml
>>>>>
>>>>> <release>2.0.0-pre20</release>
>>>>>
>>>>> On Thursday, November 6, 2014 5:50:14 PM UTC-5, Henrik Eneroth wrote:
>>>>>
>>>>> Thanks for looking into it, Micha!
>>>>>>
>>>>>>
>>>>>> I'm getting -pre19 with boot -u, though. Did you forget to cut a
>>>>>> release or should I set BOOT_CHANNEL to dev?
>>>>>>
>>>>>>
>>>>>> On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>>>>>>>
>>>>>>> Hi Henrik,
>>>>>>>
>>>>>>> You found a bug! We just fixed it though. Boot was confused by
>>>>>>> `reagent/reagent` when it tried to match that against the artifact ids
>>>>>>> returned by Pomegranate, because Pomegranate collapses it to just
>>>>>>> `reagent`
>>>>>>> in that case. If you do `boot -u` you should be updated to boot version
>>>>>>> `2.0.0-pre20`, and your command line will work.
>>>>>>>
>>>>>>> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello Micha!
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm trying to tuck Reagent in there to take it for a spin, and it
>>>>>>>> seems reluctant to comply:
>>>>>>>>
>>>>>>>> boot -d reagent/reagent:0.4.3
>>>>>>>> java.lang.NullPointerException:
>>>>>>>> boot.main/dep-ns-decls main.clj: 36
>>>>>>>> boot.main/export-task-namespaces/fn main.clj: 49
>>>>>>>> clojure.core/map/fn core.clj: 2557
>>>>>>>> ...
>>>>>>>> clojure.core/seq core.clj: 133
>>>>>>>> clojure.core/apply core.clj: 624
>>>>>>>> clojure.core/mapcat core.clj: 2586
>>>>>>>> ...
>>>>>>>> boot.main/export-task-namespaces main.clj: 51
>>>>>>>> boot.main/-main main.clj: 111
>>>>>>>> ...
>>>>>>>> boot.App.runBoot App.java: 217
>>>>>>>> boot.App.main App.java: 309
>>>>>>>>
>>>>>>>>
>>>>>>>> Any feedback on what I (or it) may be doing wrong?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Henrik
>>>>>>>>
>>>>>>>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:
>>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> Boot (http://github.com/boot-clj/boot) is a build tool for
>>>>>>>>> Clojure. We've pulled together lessons learned from a year or so
>>>>>>>>> using boot
>>>>>>>>> v1 in production and are now getting ready to release v2. To show
>>>>>>>>> what boot
>>>>>>>>> can do we present a very streamlined and awesome boot-based
>>>>>>>>> ClojureScript
>>>>>>>>> development workflow (http://adzerk.com/blog/2014/1
>>>>>>>>> 1/clojurescript-builds-rebooted/).
>>>>>>>>>
>>>>>>>>> Try it out, maybe you'll like it! We're hoping to get some
>>>>>>>>> feedback before committing to a stable release, so please if you have
>>>>>>>>> any
>>>>>>>>> comments or questions we'd be happy to hear them. Have fun!
>>>>>>>>>
>>>>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Laurent Petit
>>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/YAckwMSfZkY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Laurent Petit
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
