Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure builds as an amalgamation of orthogonal parts

blog.fogus.me

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Clojure builds as an amalgamation of orthogonal parts

#91

Post by capableweb »

brundolf wrote: post #90
capableweb wrote: post #87

Earlier quoted context omitted.

I'm not sure how they can make it easier than what it currently is, no need for any unofficial channels. If you follow the guide at https://clojure.org/guides/getting_started to install Clojure, you'll end up with `clj` in your `$PATH`, and then it is as easy as it is with Python, unless I misunderstand what you mean. $ clj --version Clojure CLI version 1.10.3.849 $ echo "(println \"hello world\")" >> hello-world.clj…

This was three or four years ago so it's very possibly changed since then (in fact the OP was specifically about this story changing)

Yeah, three or four years ago (before Clojure Tools), you'd have to do something like this:

    $ java -cp clojure.jar clojure.main hello-world.clj
Still, I'd argue it's about the same as Python, at least for the most basic use case, like what you were complaining about in your previous comment.

Re: Clojure builds as an amalgamation of orthogonal parts

#92

Post by dustingetz »

filoeleven wrote: post #84
dustingetz wrote: post #32

Earlier quoted context omitted.

i agree that it’s possible to have both, but you have to start with simple, and as he said in the talk which we just reread, easy is often relative to your local priors also those custom hand rolled fns are … a library, which is way better than a build plugin

Thanks. I didn’t even know that leinengen has plugins. If tools.* is the language maintainers’ preferred method, I think there is value in having a single command to set up a “simple/default Clojure project” in a folder, even if that only cuts the commands down from four to one. $ mkdir hello-world $ cp deps.edn hello-world $ cd hello-world $ mkdir src I don’t understand where that deps.edn comes from in a fresh proj…

{:paths ["src"] :deps {org.clojure/clojure {:mvn/version "1.10.0"}}}

that's it

Re: Clojure builds as an amalgamation of orthogonal parts

#93

Post by seancorfield »

bm3719 wrote: post #65
seancorfield wrote: post #39

Earlier quoted context omitted.

That isn't a project deps.edn file though -- it's a compendium of tools that are available for the CLI/deps.edn and I put it together as a working example so folks coming to the CLI/deps.edn stuff could see the broad range of tools available and could copy'n'paste any useful bits they want. The README explains that and even links to a better-documented and more carefully curated set of aliases that folks might want t…

Thanks for the reply. While you're here, I'll say that your resources for the CLI stuff made it possible to use those tools at all (for my current Clojure team) several years ago. depstar also is a great resource. We had to scour the internet and engage in weeks of teeth grinding to get CLI/deps to do all the things our project needed.

Thank you. As someone who follows the (b)leading edge of Clojure and its tooling very closely -- and has run alphas of Clojure itself in production since 2011 -- it's very hard for me now to put myself in the shoes of someone coming new to this tooling (unfortunately).

I think perhaps the biggest issue for most people is discoverability: how do I learn about the tools I need to get "task X" done with the Clojure CLI, deps.edn, and associated "stuff".

Even though I created clj-new (and boot-new, on which it is based, which in turn was based on lein's new), I pretty much never use it myself, except for quick examples to test stuff and/or help beginners with. I always start a project from scratch with an empty deps.edn and an initial src/myns/myfile.clj or similar.

I use depstar heavily but I strongly suspect that it will ultimately go away as tools.build matures to the point where all the special cases that depstar handles today are folded into t.b.api/jar and t.b.api/uber -- I don't want to maintain something that duplicates what the core team have poured so much time, effort, and careful thought into!

I'm already contemplating a "reboot" of clj-new as a very simple wrapper around t.b.api/copy-dir with some simple templates -- since that's most of what clj-new does (even the more complex template-running stuff is really only a slight augmentation of t.b.api's create-basis + java-command + process).

Re: Clojure builds as an amalgamation of orthogonal parts

#94

Post by seancorfield »

dustingetz wrote: post #92
filoeleven wrote: post #84

Earlier quoted context omitted.

Thanks. I didn’t even know that leinengen has plugins. If tools.* is the language maintainers’ preferred method, I think there is value in having a single command to set up a “simple/default Clojure project” in a folder, even if that only cuts the commands down from four to one. $ mkdir hello-world $ cp deps.edn hello-world $ cd hello-world $ mkdir src I don’t understand where that deps.edn comes from in a fresh proj…

{:paths ["src"] :deps {org.clojure/clojure {:mvn/version "1.10.0"}}} that's it

You don't even need that -- those are the defaults for the CLI.

    (! 639)-> mkdir fresh && cd fresh
    (! 640)-> mkdir -p src/myns
    (! 641)-> echo '(ns myns.myfile) (defn foo [{:keys [name]}] (println (str "Hello, " name "!")))' > src/myns/myfile.clj
    (! 642)-> clojure -X myns.myfile/foo :name "filoeleven"
    Hello, filoeleven!
No deps.edn file needed -- until you want to add extra dependencies etc.

Re: Clojure builds as an amalgamation of orthogonal parts

#95

Post by seancorfield »

filoeleven wrote: post #84
dustingetz wrote: post #32

Earlier quoted context omitted.

i agree that it’s possible to have both, but you have to start with simple, and as he said in the talk which we just reread, easy is often relative to your local priors also those custom hand rolled fns are … a library, which is way better than a build plugin

Thanks. I didn’t even know that leinengen has plugins. If tools.* is the language maintainers’ preferred method, I think there is value in having a single command to set up a “simple/default Clojure project” in a folder, even if that only cuts the commands down from four to one. $ mkdir hello-world $ cp deps.edn hello-world $ cd hello-world $ mkdir src I don’t understand where that deps.edn comes from in a fresh proj…

If you're using the latest (prerelease) version of the Clojure CLI:

    # this is a one-off step to install the clj-new tool:
    (! 646)-> clojure -Ttools install com.github.seancorfield/clj-new '{:git/tag "v1.1.324"}' :as new
    Installed new
    # now you can run it anywhere to create new app or lib projects:
    (! 647)-> clojure -Tnew app :name myname/myapp
    Generating a project called myapp based on the 'app' template.
    (! 648)-> tree myapp
    myapp
    |____.gitignore
    |____.hgignore
    |____CHANGELOG.md
    |____deps.edn
    |____doc
    | |____intro.md
    |____LICENSE
    |____pom.xml
    |____README.md
    |____resources
    | |____.keep
    |____src
    | |____myname
    | | |____myapp.clj
    |____test
    | |____myname
    | | |____myapp_test.clj
This is already set up with testing and JAR building for you:

    (! 649)-> cd myapp
    (! 650)-> clojure -X:test
    
    Running tests in #{"test"}

    Testing myname.myapp-test

    FAIL in (a-test) (myapp_test.clj:7)
    FIXME, I fail.
    expected: (= 0 1)
      actual: (not (= 0 1))
    
    Ran 1 tests containing 1 assertions.
    1 failures, 0 errors.
    (! 651)-> clojure -X:uberjar
    [main] INFO hf.depstar.pom - Synchronizing pom.xml
    Skipping paths: resources
    [main] INFO hf.depstar.aot - Compiling myname.myapp ...
    [main] INFO hf.depstar.uberjar - Building uber jar: ./myapp.jar
    [main] INFO hf.depstar.uberjar - Processing pom.xml for {net.clojars.myname/myapp {:mvn/version "0.1.0-SNAPSHOT"}}
    (! 652)-> java -jar myapp.jar 
    Hello, World!

Re: Clojure builds as an amalgamation of orthogonal parts

#96

Post by puredanger »

geokon wrote: post #85
puredanger wrote: post #79

Earlier quoted context omitted.

gists are git repos and can contain multiple files. Since clj supports git deps, you've been able to use them as deps for a long time. Example gist: https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632... Run it: clj -Sdeps '{:deps {a/gist {:git/url " https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632... " :sha "116ac594c922be6ed9d3366f5ac89ed2b0a082f5"}}}' -X foo/bar :name '"Alex"'

that's pretty cool! I guess gists are a bit fancier than a normal pastebin. They don't really advertise it and they don't even display the sha hashs. I didn't realize that :) and thank you for the demo. With the`:paths ["."]` you flatten the project and minimize the example size. It would make demos look much better In the end it's not quite as ergonomic as using `add-libs`, but it something that works today. Hope`ad…

add-libs is definitely still on the future list!

Re: Clojure builds as an amalgamation of orthogonal parts

#97

Post by geokon »

puredanger wrote: post #96
geokon wrote: post #85

Earlier quoted context omitted.

that's pretty cool! I guess gists are a bit fancier than a normal pastebin. They don't really advertise it and they don't even display the sha hashs. I didn't realize that :) and thank you for the demo. With the`:paths ["."]` you flatten the project and minimize the example size. It would make demos look much better In the end it's not quite as ergonomic as using `add-libs`, but it something that works today. Hope`ad…

add-libs is definitely still on the future list!

Looking forward :) I just know getting things in core is difficult b/c understandably you wanna keep most things out in utils libs.

But if you wanna have launchable scripts/code-snippets then having to ask people to append -Sdeps blahblah complicates things a bit

btw, I had a question about dependencies resolution that's always been a bit mysterious for me

from: https://insideclojure.org/2018/05/04/add-lib/ "Additionally, this code is not just blindly adding dependencies you ask for but is actually considering them in the context of the dependencies already on your classpath. So if for example, you already had a version of org.clojure/data.priority-map above, it would do the dependency resolution in the context of that version and not resolve to or add a new version to the classpath."

If you have libraries A and B and they depends on library C. Say A has it tagged at version v1.234 and B has it tagged at v1.345. From the doc's glossary it sounds like it will just get the latest version and hope nothing breaks. https://clojure.org/reference/deps_and_cli#_glossary

I haven't had it happened, but I could imagine a scenario where you add library B and library A starts to misbehave. And if I understand correctly, there is no way to have multiple versions of a library in the path. Is that right?

I know in C++ world this is a big unspoken issue. Package managers usually just mash things with the latest version and hope it works, while some build systems (like Hunter) will modify symbols so you can link to two copies.

Re: Clojure builds as an amalgamation of orthogonal parts

#99

Post by monsieurbanana »

geokon wrote: post #76
capableweb wrote: post #73

Earlier quoted context omitted.

> I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started Clojure (seems to me at least) has always preferred to cater to professionals who want to learn languages, tools and concepts deeply rather than being quick to learn. So naturally, the ecosystem tends to lean towards simple tools you use as building blocks rather than one-size-fits-them-all ala Ruby…

The tools pay off for sure but even once you know how to use deps.edn and company, I'd argue you still really need quick one-file programs. It's not just about education (though that's important as well). I think the top two use-cases are scripts and issues. Issues, .. well you want to be a nice dev and post issues with some sample code that reproduces the problem.. but you don't want to have make a whole repo (and t…

Babashka fills the scripts / one-file programs niche rather well. It comes with many built-in libraries[0], add-libs equivalent, and very fast startup time

[0] https://book.babashka.org/#libraries

Post reply on HN