Re: Rationale: cljctools.mult - hypothetical clojure(script) extension for vscode. Should mult be made? Critique, comments ?

[Sergei Udris]

Do appreciate your response, better than I hoped for, will digest it and 
take into consideration.
The goal is not vanity, but creating value, so mult is not a rush to prove 
oneself. 
Will take all the critique and comments and seriously think whether or not 
mult brings value. If not, I won't waste time with it.

>> Why is it a goal to write an editor in Clojure? Would this editor be a 
general one, or would it be a Clojure editor? 
- if vscode is the current best, even that can be improved (but that's a 
rationale of its own) 
- a general one
>> That makes me think about Clover, from the same author as Chlorine for 
Atom
- did not no about those tools, definitely will take a look, thank you
>> so that Clover could benefit from some of the work that has been put 
into making Calva nice
- Calva is indeed a trailblazing project and amazing work
>> One way forward for mult could be to pick up Clover + help in 
refactoring Calva to make parts of it usable by Clover users
- yes, that was my initial thinking, that's why I forked Calva and wanted 
to modify it for my needs
- I lived and breathed Typescript for many years, did multiple large 
commercial monster projects in it, so I thought I just tweak Calva and make 
it mult-y
- but doing things in clojure(script) is much more productive, especially 
handling asynchrony with core.async (CSP) - that has no analogs, besides 
golang, so core.async is the key
 >> but always found my time to be too limited to not spend on actually 
making Calva more usable instead
- oh, I can't thank you enough, without Calva it would be dim, and I do 
understand that it's not all rainbows and unicorns, sometimes one just 
needs to get it done 
>> I think (and maybe it is me being biased) that beginning Clojurians 
benefit from one clear option for VS Code, so I think the second way 
forward there is the best.
- I disagree, I think choice(options) is better
- but again, mult is under question and will be thoroughly considered

On Tuesday, August 11, 2020 at 11:47:48 AM UTC+3 Peter Strömberg wrote:

> Looks super interesting! Some quick thoughts/questions:
>
> Why is it a goal to write an editor in Clojure? Would this editor be a 
> general one, or would it be a Clojure editor? 
>
> I am of course happy you see Calva as a good option for Clojure coding. I 
> think the major thing lacking from it is Socket REPL support. That makes me 
> think about Clover, from the same author as Chlorine for Atom. Chlorine 
> ticks off a lot of your boxes. Clover is currently of a much more limited 
> use than Chlorine, because reasons. One of which is that Clojure coding is 
> about more than the REPL, and some of that is a lot of work and Calva is a 
> bit of a monolith making its formatter and stuff part of the Calva package 
> only. I have tried to refactor Calva some to make it less monolithic so 
> that Clover could benefit from some of the work that has been put into 
> making Calva nice. But I got stuck, or rather ran out of time. One way 
> forward for mult could be to pick up Clover + help in refactoring Calva to 
> make parts of it usable by Clover users.
>
> Another way forward could be to start porting more of Calva to 
> ClojureScript (it is partly written in CLJS, actually). I have made several 
> attempts at this, but always found my time to be too limited to not spend 
> on actually making Calva more usable instead.
>
> I think (and maybe it is me being biased) that beginning Clojurians 
> benefit from one clear option for VS Code, so I think the second way 
> forward there is the best.
>
> I'm plugging the Tao of Calva here, for easy comparison between the goals 
> of mult and the goals of Calva: 
> https://github.com/BetterThanTomorrow/calva/wiki
>
> Regards,
> /Peter
>
> On Tue, Aug 11, 2020 at 8:29 AM Sergei Udris  wrote:
>
>> # mult: hypothetical clojure(script) extension for vscode
>>
>> https://github.com/cljctools/mult
>>
>> ## rationale
>>
>> - clojure(script) IDE experience is no minor issue - it's the thing 
>> between you and programs
>>
>> - the editor and the extension 
>>   - should be long-term satisfactory, enjoyable and even inspiring
>>   - should be open source
>>   - should be written in clojure, or at least the extension should be 
>> written in clojure(script)
>> - for simplicity
>> - for asynchrony done via processes
>> - the extension should
>>   - support multiple repl connections from one editor window
>>   - have a file configuration (for user and projects), where connections and 
>> repls can be specified (to not depend on key-combo connection sequences)
>>   - be simpler, code-wise and feature-wise 
>> - making an editor in clojure is, no doubt, a goal, but the extension for an 
>> existing editor is a logical first step
>>   - the work of making an extension is trasferrable even into an editor 
>> written in clojure, so the work won't be lost
>> - existing editor + extension combos
>>   - Emacs + Cider
>> - perfect, if you're into it
>>   - 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['bed...@yahoo.com' via Clojure]

Ok, let's reset as we start talking about different things now.

None of these libraries are broken. They just include resources. Also, I 
don't think it is realistic to tell library authors to please move certain 
files out of the way because my build tool randomizes my classpath. That is 
not going to happen. People will keep including things like 
log4j.properties that are in potential conflict with a local file or files 
in other JAR paths.

The question remains: Should my build tool allow me control over the order 
of the classpath? I believe the answer is yes. 
(Even gradle gives you that control and/or offers ways to ensure that my 
chosen paths and libraries are first on the classpath.
Regarding maven: Even if there would be no documentation at all, their 
algorithm has not changed since 2.0.9. It's the Normative Kraft des 
Faktischen at play. )

If the build tool from version A to version B changes this order, it is not 
a usable tool. I can't make this point any clearer.
We might agree to disagree here, but a build tool should not be at liberty 
to sort top-level dependencies at will.

Note that this is completely independent from the thought that order 
*shouldn't* matter.
When in fact it does matter. It is an unfortunate reality. That's simply 
how resource loading works in Java.

I understand that building dependency trees is not trivial, but it is 
rather trivial to ensure :paths comes before everything else.
Please define some stable order and establish a top-level order for 
explicit dependencies. That makes builds deterministic.

Thanks for looking in this issue,
 Jochen

PS: happy to learn you got in touch with the homebrew team. That is 
excellent news.




On Tuesday, August 11, 2020 at 6:01:18 PM UTC-7 Alex Miller wrote:

> On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>
>> Just 2 quick points before I go back to migrate to shadow-cljs & 
>> leiningen ;)
>>
>> "just does not seem well defined "
>> This is not a line of argument you want to pursue when we are talking 
>> about maven, who has had a stable order for what feels like decades now.
>> If you need a current link: 
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
>> (search for "first")
>>
>
> I understand it may feel like that to you, but I have been using Maven for 
> at least 15 years and have spent a lot of time fighting classpath ordering 
> issues while using it. That link says nothing about classpath order and I 
> spent some more time today looking for something like that, without 
> success. There are plenty of Maven tickets about this, it's changed over 
> the years, and a lot of complexity to cover when you start to consider 
> parent poms, dependency management, etc. I don't think it's as fixed as you 
> think it is, probably more that they just don't touch it much (and most 
> differences don't actually matter). It may be stable largely by fear.
>  
>
>> To your comment re Intellij: you can actually use Intellij to build and 
>> it uses its own project configuration to do that and cobble together the 
>> classpath (in many cases it merely syncs with maven/lein etc.). In a way, 
>> Intellij acts like clj: It builds a classpath and runs stuff.
>>
>
> Yeah, I use it every day. My point was just that it's independent from 
> what we're talking about.
>  
>
>> Also, arguing that "JARs need to be fixed" is interesting,  as I can get 
>> *any* resource with `(io/resource...)` and will get different answers 
>> depending on CLASSPATH order. 
>>
>
> You can only get different answers if two roots have the same resource, 
> which again, is bad, and the cause of a big percentage of dependency issues 
> I've tracked down at one point or another. Same resource = shadowing = 
> eventually you will reorder your deps and see something different.
>  
>
>> If that order changes in between minor versions of clj, that makes it an 
>> unstable build system.
>>
>
> I'd say if that's coming from dependencies, then it's your build deps that 
> are unstable, you just didn't know it. The ordering of project paths before 
> deps is a separate issue.
>  
>
>> Just try to io-resource '/log4j.properties', for funsies. If in version A 
>> of clj I'm getting my own /log4j.properties and in version I'm getting the 
>> one from some other JAR, it's a problem.
>>
>> If I run 
>> find . -name "*.jar" -exec unzip -l {} \; | awk '{print $4}' | sort | less
>> in ~/.m2
>> to crudely get all file names for all my cached jars,
>> I can find 4 instances of 'public/index.html' 
>> 3 of 'public/css/style.css' etc. etc.
>>
>
> You are proving my point. That's all broken. Those libs cannot control 
> where they are placed in an application's classpath and whether they will 
> shadow or be shadowed by something else. They are time bombs waiting to 
> break your build. You should complain to their creators.
>  
>
>> Please return to at least 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['Alex Miller' via Clojure]

FYI, I've been working with the homebrew team today and homebrew-core now 
points to the latest stable clojure tools version and will track that 
automatically going forward.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/6e3a5819-8401-47fd-88b6-da6254b8cf22n%40googlegroups.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['Alex Miller' via Clojure]

On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Just 2 quick points before I go back to migrate to shadow-cljs & leiningen
> ;)
>
> "just does not seem well defined "
> This is not a line of argument you want to pursue when we are talking
> about maven, who has had a stable order for what feels like decades now.
> If you need a current link:
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
> (search for "first")
>

I understand it may feel like that to you, but I have been using Maven for
at least 15 years and have spent a lot of time fighting classpath ordering
issues while using it. That link says nothing about classpath order and I
spent some more time today looking for something like that, without
success. There are plenty of Maven tickets about this, it's changed over
the years, and a lot of complexity to cover when you start to consider
parent poms, dependency management, etc. I don't think it's as fixed as you
think it is, probably more that they just don't touch it much (and most
differences don't actually matter). It may be stable largely by fear.


> To your comment re Intellij: you can actually use Intellij to build and it
> uses its own project configuration to do that and cobble together the
> classpath (in many cases it merely syncs with maven/lein etc.). In a way,
> Intellij acts like clj: It builds a classpath and runs stuff.
>

Yeah, I use it every day. My point was just that it's independent from what
we're talking about.


> Also, arguing that "JARs need to be fixed" is interesting,  as I can get
> *any* resource with `(io/resource...)` and will get different answers
> depending on CLASSPATH order.
>

You can only get different answers if two roots have the same resource,
which again, is bad, and the cause of a big percentage of dependency issues
I've tracked down at one point or another. Same resource = shadowing =
eventually you will reorder your deps and see something different.


> If that order changes in between minor versions of clj, that makes it an
> unstable build system.
>

I'd say if that's coming from dependencies, then it's your build deps that
are unstable, you just didn't know it. The ordering of project paths before
deps is a separate issue.


> Just try to io-resource '/log4j.properties', for funsies. If in version A
> of clj I'm getting my own /log4j.properties and in version I'm getting the
> one from some other JAR, it's a problem.
>
> If I run
> find . -name "*.jar" -exec unzip -l {} \; | awk '{print $4}' | sort | less
> in ~/.m2
> to crudely get all file names for all my cached jars,
> I can find 4 instances of 'public/index.html'
> 3 of 'public/css/style.css' etc. etc.
>

You are proving my point. That's all broken. Those libs cannot control
where they are placed in an application's classpath and whether they will
shadow or be shadowed by something else. They are time bombs waiting to
break your build. You should complain to their creators.


> Please return to at least having :paths at the front of the CLASSPATH.
>

As I said, that's a different issue and I'm inclined to agree with you. The
details of changing it are more complicated than it appears.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAOdgdgx37zdsApu6zAqBFMZ-yPzGSt_OmE%3DOaW%3DywFfB3YinEQ%40mail.gmail.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['Alex Miller' via Clojure]

Can you change that resources file and see if what you're looking at
changes to double check? I did actually check a bunch of jars from the
prior message and did some searching for that message. Or you could even
dump the classpath with -Spath, then move resources to the front, then use
-Scp (which will force the classpath you say, ignoring everything else).

Or could be that it's not the index.html but something it refers to getting
picked up from elsewhere?

On Tue, Aug 11, 2020 at 6:18 PM Alan Thompson  wrote:

> Hi - I just tried your suggestion and no joy:
>
>
> ~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
> clojure.java.io/resource) \"public/index.html\")"
> DEPRECATED: Libs must be qualified, change deps-ancient =>
> deps-ancient/deps-ancient (deps.edn)
> DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
> (deps.edn)
> DEPRECATED: Libs must be qualified, change ns-tracker =>
> ns-tracker/ns-tracker (deps.edn)
> DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
> camel-snake-kebab/camel-snake-kebab (deps.edn)
> DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
> DEPRECATED: Libs must be qualified, change orchestra =>
> orchestra/orchestra (deps.edn)
> DEPRECATED: Libs must be qualified, change cljs-ajax =>
> cljs-ajax/cljs-ajax (deps.edn)
> DEPRECATED: Libs must be qualified, change expound => expound/expound
> (deps.edn)
> DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
> (deps.edn)
> DEPRECATED: Libs must be qualified, change re-frame-utils =>
> re-frame-utils/re-frame-utils (deps.edn)
> DEPRECATED: Libs must be qualified, change cljs-bean =>
> cljs-bean/cljs-bean (deps.edn)
> #object[java.net.URL 0x6c345c5f
> "file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]
>
>
> The call to `requiring-resolve` claims it is finding my local
> `./resources/public/index.html`.  However, the error remains that it is
> finding some other `index.html`, which also points to an incorrect JS
> output file.
>
> Alan
>
>
>
>
> On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
> clojure@googlegroups.com> wrote:
>
>>
>> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
>> clojure@googlegroups.com> wrote:
>>
>>> Here's some maven-specific discussion:
>>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>>> They have a defined order since 2.0.9. and declaration order is
>>> considered for transitive dependencies conflict.
>>>
>>
>> Unfortunately, neither that 11 year old SO answer nor the referenced
>> jiras actually document, explain, or refer to any documentation about the
>> ordering, or afaict commit to anything specific other than reproducibility.
>> I'm not saying this is your fault or anything, just does not seem well
>> defined to me other than as an artifact of implementation.
>>
>> For libs, Maven (and I presume lein which relies on Maven libs for this)
>> uses the ordering of deps in the pom wrt the ordering in the classpath. clj
>> intentionally does not include this ordering - the libs are in an unordered
>> map, the version selection algorithm is completely different, etc. If this
>> matters, then one of your deps is broken and should be fixed.
>>
>>
>>> Intellij's Dependencies tab in Module settings: You can re-order the
>>> dependencies and they reflect in the classpath.
>>>
>>
>> Not sure that has anything to do with Maven or lein, seems orthogonal to
>> the question here.
>>
>>
>>>
>>> lein classpath -> local paths added first, JARs afterwards
>>>
>>> Please consider returning to a :paths first, then :deps in a stable
>>> order.
>>>
>>
>> I will consider some options.
>>
>>
>>>
>>> I know it is not pretty and it is not desirable for code to be dependent
>>> on that, but resource-loading uses the CLASSPATH and that makes the order
>>> of dependencies intrinsically linked to locating resources.
>>>
>>
>>> I'd also rather fighweel-main behave differently, but it relies on
>>> (io/resource "public/index.html")
>>>
>>
>> I think that is perfectly ok - the problem here is whether a jar includes
>> that resource, which is likely to conflict. I'd be very interested to know
>> whether this is actually a jar or an issue with the ordering of your local
>> paths. To check where it's finding index.html:
>>
>> clj -e "((requiring-resolve 'clojure.java.io/resource)
>> \"public/index.html\")"
>>
>> --
>> 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 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['bed...@yahoo.com' via Clojure]

Just 2 quick points before I go back to migrate to shadow-cljs & leiningen 
;)

"just does not seem well defined "
This is not a line of argument you want to pursue when we are talking about 
maven, who has had a stable order for what feels like decades now.
If you need a current link: 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
(search for "first")

To your comment re Intellij: you can actually use Intellij to build and it 
uses its own project configuration to do that and cobble together the 
classpath (in many cases it merely syncs with maven/lein etc.). In a way, 
Intellij acts like clj: It builds a classpath and runs stuff.

Also, arguing that "JARs need to be fixed" is interesting,  as I can get 
*any* resource with `(io/resource...)` and will get different answers 
depending on CLASSPATH order. If that order changes in between minor 
versions of clj, that makes it an unstable build system.
Just try to io-resource '/log4j.properties', for funsies. If in version A 
of clj I'm getting my own /log4j.properties and in version I'm getting the 
one from some other JAR, it's a problem.

If I run 
find . -name "*.jar" -exec unzip -l {} \; | awk '{print $4}' | sort | less
in ~/.m2
to crudely get all file names for all my cached jars,
I can find 4 instances of 'public/index.html' 
3 of 'public/css/style.css' etc. etc.

Please return to at least having :paths at the front of the CLASSPATH.

Thanks,
 Jochen






On Tuesday, August 11, 2020 at 2:15:57 PM UTC-7 Alex Miller wrote:

> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>
>> Here's some maven-specific discussion: 
>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>> They have a defined order since 2.0.9. and declaration order is 
>> considered for transitive dependencies conflict.
>>
>
> Unfortunately, neither that 11 year old SO answer nor the referenced jiras 
> actually document, explain, or refer to any documentation about the 
> ordering, or afaict commit to anything specific other than reproducibility. 
> I'm not saying this is your fault or anything, just does not seem well 
> defined to me other than as an artifact of implementation.
>
> For libs, Maven (and I presume lein which relies on Maven libs for this) 
> uses the ordering of deps in the pom wrt the ordering in the classpath. clj 
> intentionally does not include this ordering - the libs are in an unordered 
> map, the version selection algorithm is completely different, etc. If this 
> matters, then one of your deps is broken and should be fixed.
>  
>
>> Intellij's Dependencies tab in Module settings: You can re-order the 
>> dependencies and they reflect in the classpath.
>>
>
> Not sure that has anything to do with Maven or lein, seems orthogonal to 
> the question here.
>  
>
>>
>> lein classpath -> local paths added first, JARs afterwards
>>
>> Please consider returning to a :paths first, then :deps in a stable order.
>>
>
> I will consider some options.
>  
>
>>
>> I know it is not pretty and it is not desirable for code to be dependent 
>> on that, but resource-loading uses the CLASSPATH and that makes the order 
>> of dependencies intrinsically linked to locating resources. 
>>
>
>> I'd also rather fighweel-main behave differently, but it relies on 
>> (io/resource "public/index.html")
>>
>
> I think that is perfectly ok - the problem here is whether a jar includes 
> that resource, which is likely to conflict. I'd be very interested to know 
> whether this is actually a jar or an issue with the ordering of your local 
> paths. To check where it's finding index.html:
>
> clj -e "((requiring-resolve 'clojure.java.io/resource) 
> \"public/index.html\")"
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/2e38671c-901d-4ee1-a598-4a0f8ef520fen%40googlegroups.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Alan Thompson]

Hi - I just tried your suggestion and no joy:


~/work/tmp810/xanadu >   clj -e "((requiring-resolve '
clojure.java.io/resource) \"public/index.html\")"
DEPRECATED: Libs must be qualified, change deps-ancient =>
deps-ancient/deps-ancient (deps.edn)
DEPRECATED: Libs must be qualified, change reagent => reagent/reagent
(deps.edn)
DEPRECATED: Libs must be qualified, change ns-tracker =>
ns-tracker/ns-tracker (deps.edn)
DEPRECATED: Libs must be qualified, change camel-snake-kebab =>
camel-snake-kebab/camel-snake-kebab (deps.edn)
DEPRECATED: Libs must be qualified, change bidi => bidi/bidi (deps.edn)
DEPRECATED: Libs must be qualified, change orchestra => orchestra/orchestra
(deps.edn)
DEPRECATED: Libs must be qualified, change cljs-ajax => cljs-ajax/cljs-ajax
(deps.edn)
DEPRECATED: Libs must be qualified, change expound => expound/expound
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame => re-frame/re-frame
(deps.edn)
DEPRECATED: Libs must be qualified, change re-frame-utils =>
re-frame-utils/re-frame-utils (deps.edn)
DEPRECATED: Libs must be qualified, change cljs-bean => cljs-bean/cljs-bean
(deps.edn)
#object[java.net.URL 0x6c345c5f
"file:/Users/alanthompson/work/tmp810/xanadu/resources/public/index.html"]


The call to `requiring-resolve` claims it is finding my local
`./resources/public/index.html`.  However, the error remains that it is
finding some other `index.html`, which also points to an incorrect JS
output file.

Alan




On Tue, Aug 11, 2020 at 2:15 PM 'Alex Miller' via Clojure <
clojure@googlegroups.com> wrote:

>
> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
> clojure@googlegroups.com> wrote:
>
>> Here's some maven-specific discussion:
>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>> They have a defined order since 2.0.9. and declaration order is
>> considered for transitive dependencies conflict.
>>
>
> Unfortunately, neither that 11 year old SO answer nor the referenced jiras
> actually document, explain, or refer to any documentation about the
> ordering, or afaict commit to anything specific other than reproducibility.
> I'm not saying this is your fault or anything, just does not seem well
> defined to me other than as an artifact of implementation.
>
> For libs, Maven (and I presume lein which relies on Maven libs for this)
> uses the ordering of deps in the pom wrt the ordering in the classpath. clj
> intentionally does not include this ordering - the libs are in an unordered
> map, the version selection algorithm is completely different, etc. If this
> matters, then one of your deps is broken and should be fixed.
>
>
>> Intellij's Dependencies tab in Module settings: You can re-order the
>> dependencies and they reflect in the classpath.
>>
>
> Not sure that has anything to do with Maven or lein, seems orthogonal to
> the question here.
>
>
>>
>> lein classpath -> local paths added first, JARs afterwards
>>
>> Please consider returning to a :paths first, then :deps in a stable order.
>>
>
> I will consider some options.
>
>
>>
>> I know it is not pretty and it is not desirable for code to be dependent
>> on that, but resource-loading uses the CLASSPATH and that makes the order
>> of dependencies intrinsically linked to locating resources.
>>
>
>> I'd also rather fighweel-main behave differently, but it relies on
>> (io/resource "public/index.html")
>>
>
> I think that is perfectly ok - the problem here is whether a jar includes
> that resource, which is likely to conflict. I'd be very interested to know
> whether this is actually a jar or an issue with the ordering of your local
> paths. To check where it's finding index.html:
>
> clj -e "((requiring-resolve 'clojure.java.io/resource)
> \"public/index.html\")"
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAOdgdgz88M5jfbSOb2yTkehh3b32uQ6rh0bqa44T7J7hnP7LBQ%40mail.gmail.com
> 
> .
>

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

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['Alex Miller' via Clojure]

On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Here's some maven-specific discussion:
> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
> They have a defined order since 2.0.9. and declaration order is considered
> for transitive dependencies conflict.
>

Unfortunately, neither that 11 year old SO answer nor the referenced jiras
actually document, explain, or refer to any documentation about the
ordering, or afaict commit to anything specific other than reproducibility.
I'm not saying this is your fault or anything, just does not seem well
defined to me other than as an artifact of implementation.

For libs, Maven (and I presume lein which relies on Maven libs for this)
uses the ordering of deps in the pom wrt the ordering in the classpath. clj
intentionally does not include this ordering - the libs are in an unordered
map, the version selection algorithm is completely different, etc. If this
matters, then one of your deps is broken and should be fixed.


> Intellij's Dependencies tab in Module settings: You can re-order the
> dependencies and they reflect in the classpath.
>

Not sure that has anything to do with Maven or lein, seems orthogonal to
the question here.


>
> lein classpath -> local paths added first, JARs afterwards
>
> Please consider returning to a :paths first, then :deps in a stable order.
>

I will consider some options.


>
> I know it is not pretty and it is not desirable for code to be dependent
> on that, but resource-loading uses the CLASSPATH and that makes the order
> of dependencies intrinsically linked to locating resources.
>

> I'd also rather fighweel-main behave differently, but it relies on
> (io/resource "public/index.html")
>

I think that is perfectly ok - the problem here is whether a jar includes
that resource, which is likely to conflict. I'd be very interested to know
whether this is actually a jar or an issue with the ordering of your local
paths. To check where it's finding index.html:

clj -e "((requiring-resolve 'clojure.java.io/resource)
\"public/index.html\")"

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAOdgdgz88M5jfbSOb2yTkehh3b32uQ6rh0bqa44T7J7hnP7LBQ%40mail.gmail.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['bed...@yahoo.com' via Clojure]

Here's some maven-specific discussion: 
https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
They have a defined order since 2.0.9. and declaration order is considered 
for transitive dependencies conflict.

Intellij's Dependencies tab in Module settings: You can re-order the 
dependencies and they reflect in the classpath.

lein classpath -> local paths added first, JARs afterwards

Please consider returning to a :paths first, then :deps in a stable order.

I know it is not pretty and it is not desirable for code to be dependent on 
that, but resource-loading uses the CLASSPATH and that makes the order of 
dependencies intrinsically linked to locating resources.

I'd also rather fighweel-main behave differently, but it relies on 
(io/resource "public/index.html")

Thanks,
 Jochen



On Tuesday, August 11, 2020 at 11:55:07 AM UTC-7 Alex Miller wrote:

> Just to beat the horse...
>
> On Tue, Aug 11, 2020 at 1:05 PM 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>
>> Changing the order of classpath entry and not having paths be at the 
>> beginning of the CLASSPATH will break existing code that uses `(io/resource 
>> ...)` to load resources from the CLASSPATH.
>> While in theory the order of the classpath should not matter, in practice 
>> it does, often involuntarily.
>>
>
> Just to reiterate so it's clear, this is bad, at least for deps and 
> usually for most other uses. That's why we provide features in deps.edn to 
> encourage you to be specific when you are overriding something that exists 
> in the classpath rather than relying on an ordering mechanism. If there is 
> a use case where shadowing is a feature and not a bug that is not already 
> covered, I'd be interested in hearing about it.
>  
>
>> Fighweel-main's default behavior is to load `public/index.html` which 
>> works fine if the local paths come first, but will fail if any other JAR 
>> has a `public/index.html` resource.
>>
>> And as we learned, they do!
>>
>
> This is bad, and we should loudly complain about it to whoever is doing 
> it, not just accept it. (It's probably accidental, not intentional.)
>  
>
>> Please consider going back to the old, defined behavior.
>>
>
> I am considering options. 
>  
>
>> All other build tools I know have - for good or bad - a defined CLASSPATH 
>> order.
>>
>
> Do they? I'm not aware of documentation about or guarantees for this with 
> either lein or Maven but would love to be pointed at those docs if you're 
> aware of something. Both Maven and lein have considered how to make builds 
> repeatable/reproducible, but I'm actually not aware that the order is well 
> defined and documented (and I have looked).
>
>  
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/f773ded2-f44e-4222-9d10-07b1c5a9caf2n%40googlegroups.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['Alex Miller' via Clojure]

Just to beat the horse...

On Tue, Aug 11, 2020 at 1:05 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:

> Changing the order of classpath entry and not having paths be at the
> beginning of the CLASSPATH will break existing code that uses `(io/resource
> ...)` to load resources from the CLASSPATH.
> While in theory the order of the classpath should not matter, in practice
> it does, often involuntarily.
>

Just to reiterate so it's clear, this is bad, at least for deps and usually
for most other uses. That's why we provide features in deps.edn to
encourage you to be specific when you are overriding something that exists
in the classpath rather than relying on an ordering mechanism. If there is
a use case where shadowing is a feature and not a bug that is not already
covered, I'd be interested in hearing about it.


> Fighweel-main's default behavior is to load `public/index.html` which
> works fine if the local paths come first, but will fail if any other JAR
> has a `public/index.html` resource.
>
> And as we learned, they do!
>

This is bad, and we should loudly complain about it to whoever is doing it,
not just accept it. (It's probably accidental, not intentional.)


> Please consider going back to the old, defined behavior.
>

I am considering options.


> All other build tools I know have - for good or bad - a defined CLASSPATH
> order.
>

Do they? I'm not aware of documentation about or guarantees for this with
either lein or Maven but would love to be pointed at those docs if you're
aware of something. Both Maven and lein have considered how to make builds
repeatable/reproducible, but I'm actually not aware that the order is well
defined and documented (and I have looked).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAOdgdgxk7C%2Bv_N6quG2tJJU1ZKPS2h55vxwMyyH6W%2BUQ93vABQ%40mail.gmail.com.

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

['bed...@yahoo.com' via Clojure]

Changing the order of classpath entry and not having paths be at the 
beginning of the CLASSPATH will break existing code that uses `(io/resource 
...)` to load resources from the CLASSPATH.
While in theory the order of the classpath should not matter, in practice 
it does, often involuntarily.
Fighweel-main's default behavior is to load `public/index.html` which works 
fine if the local paths come first, but will fail if any other JAR has a 
`public/index.html` resource.

And as we learned, they do!

Please consider going back to the old, defined behavior. All other build 
tools I know have - for good or bad - a defined CLASSPATH order.

Thanks, Jochen

On Monday, August 10, 2020 at 9:08:00 PM UTC-7 Alex Miller wrote:

> Bunch of things here...
>
> Clojure maintains its own brew tap and a "stable" release that you can 
> obtain with `brew install clojure/tools/clojure` (the brew conventions 
> automatically find the prior repo based on that). That tap also includes 
> prerelease unstable versions that can be obtained with "@version" - more on 
> that is doc'ed in the readme for that repo. The current stable version is 
> 1.10.1.561.
>
> Homebrew core is what you are pulling from if you just do `brew install 
> clojure`. The formula there is no longer maintained by the Clojure team as 
> anyone can update it (and have, with changes we did not agree with). There 
> is no "ownership" model in homebrew-core. I would happily remove it from 
> there but they said they would not accept that PR. Recently, the 
> homebrew-core formula has been updated by members of the homebrew team to 
> newer prerelease (not yet stable) versions of clj. There is not really 
> anything we can do about this.
>
> The classpath difference is interesting. The classpath is a set of path 
> roots and in general the files in these paths should be mutually exclusive. 
> If the roots are mutually exclusive, then the classpath order is 
> unimportant (as the JVM will always find the same class/clj/resource file 
> regardless). Roots that include the same file are nearly always trouble and 
> the source of "jar hell" style problems. clj and deps.edn provide features 
> to cover most of the scenarios where users are typically tempted to use 
> ordering for replacement (:override-deps, :classpath-overrides, etc).
>
> Based on this, we did knowingly make a change since the last stable 
> release that effectively made the classpath unordered (all the roots go 
> through keys of a map at one point). To date, I had not seen any issues 
> with that, so this is a useful data point we can take into consideration. I 
> assume you're getting an index.html out of some library that's either 
> unimportant or accidentally included. For now, I'd recommend that you 
> continue using the latest stable version from the official Clojure homebrew 
> tap.
>
> Re the version - you can see the version with either `clj -h` (first line) 
> or `clj -Sdescribe`. 
>
> Relevant links:
>
> * Clojure homebrew tap - https://github.com/clojure/homebrew-tools
> * Official clj stable formula - 
> https://github.com/clojure/homebrew-tools/blob/master/Formula/clojure.rb 
> (what you get with `brew install clojure/tools/clojure`)
> * Getting started/install doc - https://clojure.org/guides/getting_started
> * Homebrew core - https://github.com/Homebrew/homebrew-core
> * clj reference - https://clojure.org/reference/deps_and_cli (or see `clj 
> -h` or `man clj`)
>
>
> On Monday, August 10, 2020 at 7:04:40 PM UTC-5 cloo...@gmail.com wrote:
>
>> P.S.  There seems to be no *`clojure --version`* flag.  Should this be 
>> added to the command line tool?
>>
>>
>> On Mon, Aug 10, 2020 at 4:58 PM Alan Thompson  wrote:
>>
>>> Hi.  Just helped a colleague debug a vexing problem on a CLJS project 
>>> using Figwheel.Main.
>>>
>>> If we do *`brew install clojure/tools/clojure`*, it works:
>>>
>>> ~/work/tmp810/xanadu > clj --help
>>> Version: *1.10.1.561*
>>>
>>> Usage: clojure [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>>>clj [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>>>
>>> The clojure script is a runner for Clojure. clj is a wrapper
>>> for interactive repl use. These scripts ultimately construct and
>>> 
>>>
>>>
>>> Note that local ./resources etc are at the beginning of the classpath
>>>
>>> ~/work/tmp810/xanadu > clj -Spath
>>> *resources:target:src/clj:src/cljc:src/cljs:test/cljs:test-figwheel-main*
>>> 

Re: Classpath bug re Clojure 1.10.1.645 when using Figwheel.Main

[Thomas Heller]

This might be a good incentive for people to keep their published .jar 
files clean. Unfortunately many published CLJS libs contain the rather 
common "public" folder with "public/index.html" and often compiled .js 
artifacts which aren't actually ever used.

I do however think that it is useful to always have :paths first since it 
provides and easy way to "patch" libraries. You can just easily replace one 
namespace from a library and provide custom implementations without going 
through the entire forking process. This is used by many CLJS users as well 
since on older reagent versions it was required to stub out the reagent.dom 
[1] namepace in react-native builds. None of this is very pretty but having 
:paths first (just like lein :source-paths) at least gives you the option 
of doing this when the alternatives may be much more work.

[1] 
https://github.com/thheller/reagent-react-native/blob/master/src/main/reagent/dom.cljs

On Tuesday, August 11, 2020 at 6:08:00 AM UTC+2, Alex Miller wrote:
>
> Bunch of things here...
>
> Clojure maintains its own brew tap and a "stable" release that you can 
> obtain with `brew install clojure/tools/clojure` (the brew conventions 
> automatically find the prior repo based on that). That tap also includes 
> prerelease unstable versions that can be obtained with "@version" - more on 
> that is doc'ed in the readme for that repo. The current stable version is 
> 1.10.1.561.
>
> Homebrew core is what you are pulling from if you just do `brew install 
> clojure`. The formula there is no longer maintained by the Clojure team as 
> anyone can update it (and have, with changes we did not agree with). There 
> is no "ownership" model in homebrew-core. I would happily remove it from 
> there but they said they would not accept that PR. Recently, the 
> homebrew-core formula has been updated by members of the homebrew team to 
> newer prerelease (not yet stable) versions of clj. There is not really 
> anything we can do about this.
>
> The classpath difference is interesting. The classpath is a set of path 
> roots and in general the files in these paths should be mutually exclusive. 
> If the roots are mutually exclusive, then the classpath order is 
> unimportant (as the JVM will always find the same class/clj/resource file 
> regardless). Roots that include the same file are nearly always trouble and 
> the source of "jar hell" style problems. clj and deps.edn provide features 
> to cover most of the scenarios where users are typically tempted to use 
> ordering for replacement (:override-deps, :classpath-overrides, etc).
>
> Based on this, we did knowingly make a change since the last stable 
> release that effectively made the classpath unordered (all the roots go 
> through keys of a map at one point). To date, I had not seen any issues 
> with that, so this is a useful data point we can take into consideration. I 
> assume you're getting an index.html out of some library that's either 
> unimportant or accidentally included. For now, I'd recommend that you 
> continue using the latest stable version from the official Clojure homebrew 
> tap.
>
> Re the version - you can see the version with either `clj -h` (first line) 
> or `clj -Sdescribe`. 
>
> Relevant links:
>
> * Clojure homebrew tap - https://github.com/clojure/homebrew-tools
> * Official clj stable formula - 
> https://github.com/clojure/homebrew-tools/blob/master/Formula/clojure.rb 
> (what you get with `brew install clojure/tools/clojure`)
> * Getting started/install doc - https://clojure.org/guides/getting_started
> * Homebrew core - https://github.com/Homebrew/homebrew-core
> * clj reference - https://clojure.org/reference/deps_and_cli (or see `clj 
> -h` or `man clj`)
>
>
> On Monday, August 10, 2020 at 7:04:40 PM UTC-5 cloo...@gmail.com wrote:
>
>> P.S.  There seems to be no *`clojure --version`* flag.  Should this be 
>> added to the command line tool?
>>
>>
>> On Mon, Aug 10, 2020 at 4:58 PM Alan Thompson  wrote:
>>
>>> Hi.  Just helped a colleague debug a vexing problem on a CLJS project 
>>> using Figwheel.Main.
>>>
>>> If we do *`brew install clojure/tools/clojure`*, it works:
>>>
>>> ~/work/tmp810/xanadu > clj --help
>>> Version: *1.10.1.561*
>>>
>>> Usage: clojure [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>>>clj [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
>>>
>>> The clojure script is a runner for Clojure. clj is a wrapper
>>> for interactive repl use. These scripts ultimately construct and
>>> 
>>>
>>>
>>> Note that local ./resources etc are at the beginning of the classpath
>>>
>>> ~/work/tmp810/xanadu > clj -Spath
>>> *resources:target:src/clj:src/cljc:src/cljs:test/cljs:test-figwheel-main*
>>> 

Re: Rationale: cljctools.mult - hypothetical clojure(script) extension for vscode. Should mult be made? Critique, comments ?

[Peter Strömberg]

Looks super interesting! Some quick thoughts/questions:

Why is it a goal to write an editor in Clojure? Would this editor be a
general one, or would it be a Clojure editor?

I am of course happy you see Calva as a good option for Clojure coding. I
think the major thing lacking from it is Socket REPL support. That makes me
think about Clover, from the same author as Chlorine for Atom. Chlorine
ticks off a lot of your boxes. Clover is currently of a much more limited
use than Chlorine, because reasons. One of which is that Clojure coding is
about more than the REPL, and some of that is a lot of work and Calva is a
bit of a monolith making its formatter and stuff part of the Calva package
only. I have tried to refactor Calva some to make it less monolithic so
that Clover could benefit from some of the work that has been put into
making Calva nice. But I got stuck, or rather ran out of time. One way
forward for mult could be to pick up Clover + help in refactoring Calva to
make parts of it usable by Clover users.

Another way forward could be to start porting more of Calva to
ClojureScript (it is partly written in CLJS, actually). I have made several
attempts at this, but always found my time to be too limited to not spend
on actually making Calva more usable instead.

I think (and maybe it is me being biased) that beginning Clojurians benefit
from one clear option for VS Code, so I think the second way forward there
is the best.

I'm plugging the Tao of Calva here, for easy comparison between the goals
of mult and the goals of Calva:
https://github.com/BetterThanTomorrow/calva/wiki

Regards,
/Peter

On Tue, Aug 11, 2020 at 8:29 AM Sergei Udris  wrote:

> # mult: hypothetical clojure(script) extension for vscode
>
> https://github.com/cljctools/mult
>
> ## rationale
>
> - clojure(script) IDE experience is no minor issue - it's the thing
> between you and programs
>
> - the editor and the extension
>   - should be long-term satisfactory, enjoyable and even inspiring
>   - should be open source
>   - should be written in clojure, or at least the extension should be written 
> in clojure(script)
> - for simplicity
> - for asynchrony done via processes
> - the extension should
>   - support multiple repl connections from one editor window
>   - have a file configuration (for user and projects), where connections and 
> repls can be specified (to not depend on key-combo connection sequences)
>   - be simpler, code-wise and feature-wise
> - making an editor in clojure is, no doubt, a goal, but the extension for an 
> existing editor is a logical first step
>   - the work of making an extension is trasferrable even into an editor 
> written in clojure, so the work won't be lost
> - existing editor + extension combos
>   - Emacs + Cider
> - perfect, if you're into it
>   - IntelliJ + Cursive
> - both closed source, Cursive comes with conditions
>   - VSCode + Calva
> - can be considered the current best option
> - VSCode is the undeniable best open source editor
> - Calva works perfectly, but is written in typescript
> - nodejs runtime is undesirable, but not a problem
>
>
> Should mult be made ? Critique, comments are appreciated.
>
>
> Rationale can also be found here(same):
>
> https://github.com/cljctools/mult/blob/master/docs/design.md#rationale
>
> Same post can be found on a separate mailing list:
>
> https://groups.google.com/g/cljctools/c/Qyz0qCxVC-Y
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CA%2Bq3MLzN-X9GNyGqwPT9aHg0YNJHC_YrUR098ukhbqwWdSFcgg%40mail.gmail.com
> 
> .
>

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

Rationale: cljctools.mult - hypothetical clojure(script) extension for vscode. Should mult be made? Critique, comments ?

[Sergei Udris]

# mult: hypothetical clojure(script) extension for vscode

https://github.com/cljctools/mult

## rationale

- clojure(script) IDE experience is no minor issue - it's the thing between
you and programs

- the editor and the extension
  - should be long-term satisfactory, enjoyable and even inspiring
  - should be open source
  - should be written in clojure, or at least the extension should be
written in clojure(script)
- for simplicity
- for asynchrony done via processes
- the extension should
  - support multiple repl connections from one editor window
  - have a file configuration (for user and projects), where
connections and repls can be specified (to not depend on key-combo
connection sequences)
  - be simpler, code-wise and feature-wise
- making an editor in clojure is, no doubt, a goal, but the extension
for an existing editor is a logical first step
  - the work of making an extension is trasferrable even into an
editor written in clojure, so the work won't be lost
- existing editor + extension combos
  - Emacs + Cider
- perfect, if you're into it
  - IntelliJ + Cursive
- both closed source, Cursive comes with conditions
  - VSCode + Calva
- can be considered the current best option
- VSCode is the undeniable best open source editor
- Calva works perfectly, but is written in typescript
- nodejs runtime is undesirable, but not a problem


Should mult be made ? Critique, comments are appreciated.


Rationale can also be found here(same):

https://github.com/cljctools/mult/blob/master/docs/design.md#rationale

Same post can be found on a separate mailing list:

https://groups.google.com/g/cljctools/c/Qyz0qCxVC-Y

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CA%2Bq3MLzN-X9GNyGqwPT9aHg0YNJHC_YrUR098ukhbqwWdSFcgg%40mail.gmail.com.