We're doing this something similar with https://polytope.com 🙂

Not exactly the same thing though; we're solving a lot of similar problems that Makefiles solve, and in a "environment-agnostic" way (run locally or against the cloud with the same "makefile"). The backwards compatibility idea is really interesting. What's the use-case? Makefiles are pretty annoying to write/parse (especially if you want to support the different Make dialects)

> The backwards compatibility idea is really interesting. What's the use-case? > Basically, a zero downside "potential upgrade path". I find that Makefiles work quite well. But it's a big string with syntax, so it's hard to generate programmatically. If I had a data representation with conversion both ways, I could: • Experiment with programmatic generation of the file as data • Completely rely on make • And simply convert back to a normal Makefile if I don't want the added stuff on top of make later.

I'll read up on your stuff, thanks for the reference!

Looks like you're tackling a problem that's way more difficult than just makefiles. Interesting! Enjoying your clojure api examples right now.

Is there more information about pricing / planned business model / licensing anywhere? You mention that it's possible to run Polytope on my own infrastructure.

Looks like an end parenthesis is missing here:

Also, I'd really appreciate a "next" button in the docs. I'm realizing that this is work in progress :)

Your docs are very well written!

I'm glad you've found it interesting! We haven't published anything on pricing yet, but the gist is you can either use http://polytope.com (free to use, pay for server/disk usage), run it on-prem (free, pay for support/enterprise features), or run the CLI locally (free, period).

Yeah, the docs are a bit... incomplete. We're actually about to push a major update to them today/tomorrow

The product itself is pretty much ready to use (with some caveats) - we're further along than the docs would suggest.

Thanks for explaining! You're definitely addressing some relevant problems with current tools like Github workflows.

Good to hear! If you're interested in trying it out, I'd be happy to chat more about use-cases and/or get you in the beta (probably better suited for PM so we don't spam this channel 😉).

Babashka tasks?

yeah, babashka tasks is probably the idiomatic solution for this in most clojure projects! Bonus that you don't have to learn Makefile syntax / Makefile semantics at all, you can just write Clojure. > I'm aware that bb tasks solve a lot of related problems, but I'm specifically looking for "backwards compatibility" with plain makefiles But as far as I'm aware, there's no translation layer from/to makefile from those tasks? And then you have to model makefile dependencies not as dependencies between files, but as dependencies between which task must run first? Or is perhaps there a way to have "declarative dependencies within files" in babashka that I don't know about? --- My impression is that the idiomatic babashka solution is to model dependencies between tasks, and call out to fs/modified-since imperatively in each task? (see for example https://blog.michielborkent.nl/speeding-up-builds-fs-modified-since.html)

Or would you then just model the data dependencies in EDN, and hook into it with tasks? That could work I think :thinking_face: "It's just data"

I haven’t used hugsql. But in your question it isn’t clear what value you are trying to “send”. If you can make that more clear, people might be able to help. I will note though that double quotes and single quotes in sql are different. You’d want to use single quotes on ‘one’ and ‘two’. Single quotes make strings. Double quotes refer to sql columns and tables and such.

I am not able to convert (case id when 1 then "one" when 2 then "two end) into HugSQL syntax. I keep getting syntax error on it.

Do you get the same error when just running it as plain SQL? What is the error?

That is not something that I've ever seen advertised as part of the contract of assoc, or anything like that, but it is what the implementation happens to do for built-in Clojure maps. There might be third party implementations of maps that do replace the key object with the new key object (and its metadata, if any) on assoc operations.

from the perspective of the map, they are two identical keys

keys are compared by value equality, comparisons cannot take metadata into account.