Thanks for the advice Stu! I might give it a shot at Confluence at some
point. Just for the record, I like to defend my hypotethical approach:
Non-Clojure consumers most likely win nothing from extended metadata
facilities etc. So on second thoughts, the best default for "mylib-*1.0.0*.jar"
is to turn them off.
But on the Lein side, even if you specify [mylib *"1.0.0"*], *"*mylib-*
1.0.0-DEBUG*.jar*"* gets fetched instead unless one specifies otherwise,
which'd be the exception rather than the rule.
That way we'd get the best of both worlds - zero noise for Java consumers
or constrained Clojure envs, and full / a la carte facilities for the
majority of Clojure library producers and consumers.
On Sun, Feb 10, 2013 at 1:59 AM, Stuart Halloway
<stuart.hallo...@gmail.com>wrote:
> It is likely that, once this Pandora's box is opened, there will be more
> profiles that just debug yes/no.
>
> It is almost certain that whatever we do must be maven friendly. (Maven
> is a de facto standard for 1000x more people than leiningen, and some of
> them want to use libs written in Clojure.)
>
> If you are excited about doing this design work, please start a page in
> Confluence, and capture your goals, options, tradeoffs, and recommendations.
>
> Stu
>
>
> On Sat, Feb 9, 2013 at 7:20 PM, vemv <v...@vemv.net> wrote:
>
>> I had something like this in mind:
>>
>> - There's a set of clojure.core vars that mean something
>> (potentially) expensive yet convenient, and default to true
>> - Neither library producers or consumers have ever to touch those
>> (unless they want fine-grained control for some specific var/context)
>> - When performing a release to clojars or central, Lein creates two
>> versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
>> false, respectively
>> - Then library consumers can specify either [com.example/awesomelib *
>> "1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
>> "1.4.0-NO-DEBUG"*] in their :dependencies vector, in the
>> corresponding project.clj.
>> - If no version directive is specified, "DEBUG" would be chosen
>> unless specified otherwise in profiles.clj: {:user {:debug-dependencies
>> false}}
>>
>> Does it sound good enough?
>>
>>
>> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>>
>>> Given that: a) fns can have names for debugging purposes, and b) data
>>> structures can have metadata, wouldn't it be a good idea to let letauto
>>> attach (where possible) the names of the bindings to their
>>> corresponding values?
>>>
>>> For example, the improved let I'm thinking of would translate this
>>> input:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>> (let [foo (fn [] (throw (Exception.)))
>>> bar {:hello (/ 0 0)}]))
>>>
>>> to:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>> (let [foo (fn foo [] (throw (Exception.)))
>>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>>
>>> This could be used to increase the precision of the stack traces, or in
>>> IDEs/editors for locating the exact source of an exception.
>>>
>>> Do you see such a mechanism being incorporated to clojure.core/let -
>>> should I open a ticket?
>>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
> --
> --
> 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/groups/opt_out.
>
>
>
--
--
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/groups/opt_out.
