This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
that's how i did it in jvm clojure: https://gist.github.com/sogaiu/cfa1484d9c3ca875b13f0c3ac75c6c73
@deleted-user @holyjak I didn't add java.nio.filePaths earlier because I never could figure out how to use it from Clojure:
$ clj -e '(java.nio.file.Paths/get (into-array String "src")))'
Execution error (IllegalArgumentException) at java.lang.reflect.Array/set (Array.java:-2).
but this seems to work now:
$ bb '(java.nio.file.Paths/get "/home/justin" (into-array [".lein" "profiles.clj"]))'
#object[sun.nio.fs.UnixPath 0x566ebefb "/home/justin/.lein/profiles.clj"]
hm, I think into-array takes a seq while your 1st arg as "src" - you likely wanted ["src"]
clj-http-lite for babashka: https://github.com/borkdude/clj-http-lite/blob/master/Readme.md#babashka
@deleted-user Yeah, let's first see how this library approach pans out (e.g. the clj-http-lite one)
Adding convenience is something you can add later, but fundamentals are hard to change
@deleted-user You're free to obtain the git dep in any other way and set the classpath to the src folder
but that only works if that deps doesn't have any other deps. and dependency management is not a problem I want to re-invent the wheel for
This is a thread about self-contained scripts: https://twitter.com/ericnormand/status/1101153515584536576
@laheadle Following the example of clj-http-lite here: https://github.com/borkdude/clj-http-lite/blob/master/Readme.md#babashka I guess you could publish your curl-wrapping code also as a babashka library
This way we could have multiple competing approaches for the same problem. Over time we can see what makes sense to include in bb itself.
@deleted-user What about something like this?
#!/usr/bin/env bb
(def deps '{:deps
{clj-http-lite
{:git/url ""
:sha "f44ebe45446f0f44f2b73761d102af3da6d0a13e"}}})
(require '[clojure.java.shell :as shell])
(def classpath (:out (shell/sh "clojure" "-Sdeps" (pr-str deps) "-Spath")))
(add-to-classpath! classpath)
(require '[clj-http.lite.client :as client])
(:status (client/get "")) ;; 200
You could just ship the library in the docker container and do (add-to-classpath! "/some/dir/with/clj-http-lite/src")
. Without needing clojure
.
shipping bb + a script in a container and running it standalone is already possible today
btw, lol:
#!/usr/bin/env bb
(def deps '{:deps
{clj-http-lite
{:git/url ""
:sha "f44ebe45446f0f44f2b73761d102af3da6d0a13e"}}})
(require '[clojure.java.shell :as shell])
(def classpath (:out (shell/sh "clojure" "-Sdeps" (pr-str deps) "-Spath")))
(def script '(do (require '[clj-http.lite.client :as client])
(:status (client/get ""))))
(print (:out (shell/sh "bb" "--classpath" classpath (str script)))) ;; prints 200
The joker author told me he never wrote a multi-file script himself so far btw, so this is probably a bit speculative still
here are more: https://terminalsare.sexy/#package-managers
I mean you either use clojure / lein to pull deps, or require people to install npm, rubygems, bpkg, whatever. I guess you can just choose it for yourself and your own scripts what makes sense. If your company is heavy on JS, just put some scripts in npm?
the last time i worked with it, i recall them being very oriented toward free software only. that can be a problem for some folks who want to also use other bits. nixos on the other hand, doesn't have that kind of policy -- but last i checked they have a different significant issue.
last i checked, to use nixos requires learning a pretty not-so-nice language. guix on the other hand gives you guile.
lol. i've run systems with both for some time -- but that was a bit back. it's possible things have evolved / changed a bit.
@deleted-user Don't agree. Leiningen has a bash script to install itself and so has clojure.
Which is currently mostly brew (crossplatform for linux and mac) and maybe scoop for Windows
i'm interested in the reality of how many folks use brew for linux-ish systems -- and whether that is growing.
But maybe we're getting a bit off topic. Babashka isn't going to provide a binary packagement system, nor will it probably invent its own dependency management system.
if every ruby library had to navigate adding bin files via whatever package managers it would have seriously limited its growth
brew is also kinda nice. I guess one could write a babashka script and put it in brew with a dependency on babashka
the question is: does one make things better by inventing yet another package manager
similar -- it was way too much work. really cool stuff, but i didn't have the time or computing resources to keep up.
my uneasy management of multiple versions of things is done via things like nvm and the unfortunate java switching system provided in arch linux. some day may be some of this will be more sane.
i've looked at that a tiny bit -- but since it didn't handle java (or not well?) and i don't use most of the rest of its bits, using asdf + sdkman didn't seem like a win for me. if i used some of the other provided bits, the story might be different.
no, but you can register versions and it detects installed ones and switch more easily between them
e.g. I can also register my downloaded Graal JVM in ~/Downloads
with jenv and switch to that, per shell session, directory, system, etc
We currently use python
to start a webserver quickly during the tests, but it assumes v2 and not v3
one idea that I had was to just skip the python-required tests if python is not installed or is not v2
> We expect Unix-like software distributions (including systems like macOS and Cygwin) to install the python2 command into the default path whenever a version of the Python 2 interpreter is installed, and the same for python3 and the Python 3 interpreter. > When invoked, python2 should run some version of the Python 2 interpreter, and python3 should run some version of the Python 3 interpreter. so if macos has python2, according to the recommendations, it ought to have python2 as a name for it -- do you think that is a reasonable interpretation of what's written above?
this is from: https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors btw
i modify my local test to use python2 (the name) pretty frequently 🙂 will have to see if it works on circleci
one test is using python2 http server for testing if a socket is closed properly. since that server is single-threaded, it was blocking when a socket wasn't closed before
yeah, here would be good: https://github.com/borkdude/babashka/#test
so: trying python2, if that doesn't work, try python -V and check version, if that isn't the right version, print a warning and skip the tests that require python 2?
that would be fine by me, but like I said earlier: > I don't know if the server in python3 is multi-threaded
fwiw, some searches suggest python 3's default web server is not multithreaded -- but i'm not sure if that will remain true (if it is atm)
does this mean python apps suck for web development? I mean, you have to be able to serve two concurrent users?
the important characteristic for the test was: > since that server is single-threaded, it was blocking when a socket wasn't closed before
so you'd have to check by not closing the socket and running python3, that should result in a failing test
maybe we should just use something more internally to check this which simulates a single-threaded connection handler