Fork me on GitHub
#babashka
<
2019-12-19
>
borkdude14:12:28

Any opinions on this? Note: breaking change, need your input! https://github.com/borkdude/babashka/issues/171

sogaiu15:12:09

i don't personally mind this changing - no idea how much it is being used by others.

borkdude15:12:23

Probably not that many. There might be a few blog posts up there that need changing (cc @plexus).

borkdude15:12:10

How do people deal with binary naming conflicts in general

borkdude15:12:14

I guess if there will ever be an official debian package, it can be named babashka

borkdude15:12:23

and people can make the bb alias themselves

sogaiu15:12:27

the few times i've encountered conflicts, my resolution has been to choose between the alternatives. i.e. don't install conflicts. in nixos, there might be good ways to do this as iirc there's ways to live with multiple versions.

sogaiu15:12:39

i think the alias idea isn't bad.

sogaiu15:12:05

however, something shorter than babashka for the binary might be nicer.

sogaiu15:12:32

i think i saw that somewhere the other day -- will look

borkdude15:12:41

yeah, that was a script I made

borkdude15:12:47

a standin for the clojure script

borkdude15:12:50

but I didn't publish it yet

sogaiu15:12:58

no, somewhere else

borkdude15:12:41

Is there an official debian package for this? if not, we'll just take it 😉

sogaiu15:12:20

i guess you may be in luck here, as although the repository's name is bbk, the command appears to involve the letters "cli"

sogaiu15:12:02

haven't used it though -- so it might be worth checking a bit more carefully

borkdude15:12:29

I'm not planning to make a debian package myself, not looking forward to the bureaucracy

borkdude15:12:52

and I don't use debian

borkdude15:12:08

well, I do in fact on a server, but I can just use the installer script

sogaiu15:12:09

the .deb format is not for the faint-of-heart to be sure

sogaiu18:12:06

in option 1, it looks like some of the implementation is being exposed (because of the existence of the @) -- is that potentially an issue if there is a decision later to change the underlying implementation?

borkdude18:12:47

we can also just leave the magic as it is and only rename *in* to stdin (or some other name, I'll call that option 0)

borkdude18:12:26

So maybe option 0 is best with the least amount of breakage. Does someone object to the new name <stdin> instead of *in*?

borkdude18:12:34

maybe it doesn't play well with shell syntax?

borkdude18:12:18

seems to work:

$ bb '(def <stdin> 1) <stdin>'
1
$ bb "(def <stdin> 1) <stdin>"
1

nate19:12:21

is there a <stdin> in clojure?

nate19:12:22

btw, thank you @borkdude for the java.time.* inclusion, I'm still noodling on the idea of including tick, I need to check and see if the raw java objects are quickly usable or if a wrapper would be needed (or just nice)

borkdude19:12:33

luckily not, the idea is to chose a non-conflicting name because *in* is already taken

nate19:12:58

I only worry because < and > are important characters in bash and could be a source of confusion

borkdude19:12:45

@nate Feel free to experiment, but taking on specific libs is a bit of a commitment. I'm not sure if I want to make that commitment if there's not really a need for it. Some libs like cheshire are pretty battle tested and uncontroversial, it seems like the java time area is still a bit developing

nate19:12:59

looks like from your experiments above it works ok with ' and "

nate19:12:02

so maybe all good

borkdude19:12:10

@nate you could be right about <>, it's not really idiomatic maybe

borkdude19:12:25

but it does make the variable stand out like the earmuffs

borkdude19:12:37

and indicates that it's a special kind of thing

borkdude19:12:12

I don't know tick vs java-time well enough to make a good judgement, but it would be good to know what works and what doesn't

nate19:12:58

@borkdude I totally understand about taking on the commitment. I think that java.time.* is a great place to be for a while

nate19:12:13

I think the addition of classpath handling really makes it not matter what library is there, because you can just hide it behind a function

nate19:12:28

really excited about leveraging classpath, btw, thanks for adding that!

borkdude19:12:41

right, now there's room for experimentation

nate19:12:40

I think that leads back to the *in* thing, as having it be as compatible as possible with mainline clojure is a real benefit

nate19:12:57

then I can develop my bb libs with clojure and then call them from the CLI

borkdude19:12:24

yeah. note that clojure.core/*in* is available. it's just that user/*in* shadows it

nate19:12:46

ah, I see

borkdude19:12:58

so if you write (ns foo) *in* you already got the normal one

borkdude19:12:48

but shadowing core symbols is confusing, so it's probably better to move that to user/stdin or something

borkdude19:12:05

also it's not a dynamic var and babashka now has real dynamic vars..

borkdude19:12:13

so it's a poor name from 2 perspectives

nate19:12:03

how about bbin?

nate19:12:34

I like some sort of surrounding characters to indicate it's a special variable put there by bb

nate19:12:00

_in_ feels like an ignored variable

borkdude19:12:22

what other chars do we have

borkdude19:12:23

I've tried that in the very beginning, but that really messes with string interpolation in bash

nate19:12:33

oh right

borkdude19:12:38

that's why I ended up with *in* 🙂

nate19:12:58

I think <in> or <stdin> are the safest

borkdude19:12:23

yeah and <stdin> might be the most clear one

borkdude19:12:27

$ echo 2 | bb '(* <stdin> <stdin>)'
4

borkdude19:12:00

or just:

$ echo 2 | bb '(* <input> <input>)'
4

borkdude19:12:24

or just:

$ echo 2 | bb '(* input input)'
4

borkdude19:12:01

maybe the last one is the cleanest?

sogaiu20:12:24

i think input is likely to conflict with a user's choice

borkdude20:12:57

good point. maybe <input> is better than <stdin> since input can also be parsed EDN, instead of raw text

nate20:12:01

<input> is nice

sogaiu20:12:24

i am wondering what are the benefits of having a single thing for both parsed edn and raw text...is it not a bit entwining?

borkdude20:12:22

because you usually don't want to parse text and edn from the same stream

borkdude20:12:35

and you control what it is with the -i flag

sogaiu20:12:06

i understand that they tend to be used separately -- but is there benefit in having a single thing refer to both?

sogaiu20:12:16

could it not be more confusing?

borkdude20:12:12

well, the -i and -o flags control how input and output is read/printed. That plays well with bash text stdin/stdout. Having a separate input value to match edn/text could conflict with that

sogaiu20:12:48

as long as there is some real benefit i won't be so bothered 🙂

borkdude20:12:25

By default in and output is treated as EDN

borkdude20:12:48

but for operating with other bash commands you need to work with lines of text

borkdude20:12:58

and this is controlled by flags, not a symbol in your program

borkdude20:12:19

Introducing more magical-input values could mismatch with those flags.

sogaiu20:12:43

if you were starting from scratch, would you do the same? i thought learning to use, as well as reading the source might be less confusing.

borkdude20:12:33

I currently don't know a way to make this less confusing

sogaiu20:12:50

well, you understand better than anyone 🙂

sogaiu20:12:03

so let's just say, i don't know what i'm saying and leave it at that

sogaiu20:12:24

like in the graalvm talk, the guy said "you should stop listening to me now" 😉

borkdude20:12:49

we could do without magic input values and flags, but then your one-liners would become something like:

$ echo '{:a 1} {:a 2}' | bb -e '(vec (take-while #(not= % ::eof) (repeatedly #(edn/read {:eof ::eof} clojure.core/*in*))))'
[{:a 1} {:a 2}]

borkdude20:12:58

don't know if you like that alternative? 😉

borkdude20:12:36

and btw, you still get to do this, you don't have to use <input> if you just want to use (read-line)

sogaiu20:12:52

ah, that's nice

borkdude20:12:12

$ echo '{:a 1} {:a 2}' | bb -I '(vec <input>)'
[{:a 1} {:a 2}]

sogaiu20:12:56

i think i'm good as long as i don't have to use the magical symbols -- although i used to heavily use perl in a previous life 🙂

sogaiu20:12:19

thanks for that

borkdude20:12:44

$ echo '{:a 1} {:a 2}' | bb -I '(json/generate-string (vec <input>))'
"[{\"a\":1},{\"a\":2}]"
$ echo '{:a 1} {:a 2}' | bb -I -o '(json/generate-string (vec <input>))'
[{"a":1},{"a":2}]

sogaiu20:12:57

why not use jet? 🙂

borkdude20:12:37

because that was just a random example 😉

borkdude20:12:11

ok, we'll go with *in* -> <input> and leave it at that

sogaiu20:12:24

sounds like an improvement

borkdude20:12:51

haha, do I hear cynicism?

sogaiu20:12:19

not at all -- i really think it's better 👍

borkdude20:12:56

haha, yeah, at least people won't be confused about clojure.core/*in*

borkdude20:12:03

thanks for thinking along

sogaiu20:12:33

i hope it was slightly better than duckie

borkdude20:12:21

it's on master now... no way back 😛

sogaiu20:12:03

looks good -- those examples ran fine here (oddly enough my usual python change for the testing may not be working)

borkdude20:12:40

hmm, can you be more specific?

borkdude20:12:19

the tests do run on CI though

sogaiu20:12:52

i'm trying to narrow things down -- tests seem to hang during babashka.main-test

borkdude20:12:06

maybe in the wait-for-port test?

borkdude20:12:33

afk for a few minutes

borkdude20:12:19

btw, it could be that you have a bb socket repl running still

sogaiu20:12:35

$ lein test :only babashka.main-test/wait-for-port-test
==== Testing JVM version

lein test babashka.main-test
seems to be hung here

sogaiu21:12:58

commenting out the wait-for-port-test lets all complete from that ns:

$ lein test :only babashka.main-test
==== Testing JVM version

lein test babashka.main-test

Ran 33 tests containing 67 assertions.
0 failures, 0 errors.

sogaiu21:12:15

i confirmed that the web server started via ps

sogaiu21:12:47

there are now two instances of "python" to change -- or somehow it used to work only changing one?

sogaiu21:12:54

works now, sorry for the fuss 🙂

sogaiu21:12:04

i looked into nasus a bit, btw, but i didn't immediately figure out how to use it. may take another look.

sogaiu21:12:36

it seemed straight-forward enough to start it from the command line:

clj -Sdeps '{:deps {nasus {:mvn/version "0.1.5"}}}' -m http.server 8001
but i figured for the tests it would be nicer not to have to do that. especially on windows where the assumption of an existing installation of clj might not be a good one.

borkdude21:12:42

yeah, can't you just alias python to something else for the scope of the tests btw?

borkdude21:12:59

I don't know if this works: alias foo=bar script/test

sogaiu21:12:59

i work hard to not use aliases on my machines

sogaiu21:12:24

anyway, something like nasus would probably help us all, so i may take a look

borkdude21:12:51

the point of using python in the wait-for-port test is that it is single-threaded so it will block if the socket isn't closed

sogaiu21:12:35

in any case, starting to look for some crossplatform alternative seems like it might be good?

borkdude21:12:27

isn't python cross-platform?

borkdude21:12:16

we can just make a flag to skip those python tests if you haven't got it installed. it will be tested on CI anyway

borkdude21:12:43

and python starts fast, whereas starting a JVM process inside a test is a bit heavy imo

borkdude21:12:36

we can of course make a static binary web server for this purpose, but then we would have to make another project out of that and people would have to install that

borkdude21:12:00

there was this other jvm / clojure based webserver I also found

borkdude21:12:40

oh it was that one 🙂

borkdude21:12:46

worth a try I guess, maybe it's fast enough to start

sogaiu21:12:57

python doesn't come default with windows iirc

sogaiu21:12:03

ha ha, i thought you were about to suggest a native-image web server 😉

sogaiu21:12:14

i thought we discussed before that may be a jvm-based web server would just work off of the jvm process running the test...or may be that was for some other situation?

borkdude21:12:13

yeah, but that doesn't work from within a bb script

borkdude21:12:03

so it depends on the test

borkdude21:12:42

maybe it would be good to create an issue per test and see what we can do with it

sogaiu22:12:34

always fun to look at lists like these: https://gist.github.com/willurd/5720255