I'll answer inline below:
On Friday, November 7, 2014 12:15:55 PM UTC-5, Laurent PETIT wrote:
>
> 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?
>
Tasks are "stateful transducers", which we used to call "middleware
factories". Basically a function that returns middleware. The middleware
can be composed to obtain a handler, like in Ring. By adding the factory
level of abstraction we end up with a place to initialize local state for
our handler. This is usually achieved in a let binding that wraps the
middleware that will be returned, with the local state included in its
closure. It is here where the task would obtain temp dirs from the boot
system. The engineer writing the task is able to express their intent by
choosing an appropriate type of directory.
Files in input directories do not raise exceptions if they're not
processed. They just don't end up in the final product of the build.
Perhaps a good name for them is something like "dev files"? These are files
that are only relevant to the build process itself, basically. Boot doesn't
make assumptions about what you want to do though, so there are very few
things that boot itself will raise exceptions about.
> - 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?
>
Yes, exactly right.
> - 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?
>
Precisely. In addition it removes them from the input directories (the
exact implementation is in flux right now; we'll be landing some changes
here that preserve a clean class path such that there are not duplicate
files in different directories) and moves them to the anonymous output
directory it created.
> 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
>
Yes, I like this! Perhaps even some better way to describe these things
than "source" and "resource" exists, even. I'm all ears with respect to
naming conventions!
> Cheers,
>
> --
> Laurent
>
>
>
> 2014-11-07 16:59 GMT+01:00 Micha Niskin <micha....@gmail.com <javascript:>
> >:
>
>> 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....@gmail.com
>> <javascript:>> 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 clo...@googlegroups.com
>>> <javascript:>
>>> 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 <javascript:>
>>> 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+u...@googlegroups.com <javascript:>.
>>> 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 clo...@googlegroups.com
>> <javascript:>
>> 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 <javascript:>
>> 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 <javascript:>.
>> 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.
