Marelle: logic-based devops with Prolog | Hacker News Reader

Marelle: logic-based devops with Prolog

larsyencken.github.io

73 pointsalexatkeplar23 comments

Hi guys, I'm the author. I've been playing with this for a little while, and trying to work out an idiomatic style for it. Suggestions for improvement are most welcome.

Some pleasant parts have been writing metapackage rules. For example, playing with Julia yesterday:

  % if P is a Julia package, it's also a general package
  pkg(P) :- julia_pkg(P).

  meet(P, _) :-
    julia_pkg(P), !,
    % install the package using the Julia interpreter
    ...

  met(P, _) :-
    julia_pkg(P), !,
    % try to import the package in Julia
    ...

  julia_pkg('PyCall').
  julia_pkg('DataFrames').

The only potential problem (on the horizon) is namespacing, which IMHO Babushka does well, but which is less obvious with Prolog's fact system.

Interesting project.

The home page could use more contrast though, that grey on white is nearly unreadable.

This looks like scripting to me, not describing the desired state of a system:

    % we can install by running apt-get in shell
    meet(python, linux(_)) :-
      % could also use: install_apt('python-dev')
      bash('sudo apt-get install -y python-dev').

Give them a break. It is not prolog had been hip for a long time. Using it more idiomatically will take some practice, maybe a few web frameworks and a couple of package managers.

Give them a break? Why? They're trying to push this as a better way of managing a system.

Another failure for getting my point across on my part.

I don't see that we disagree that it is a feeble attempt at best. But consider this, who are we to judge the merits of that particular thing without more than a cursory examination? His project may as well be just a seed round away from becoming the next buzzword which people would wax poetic in the next few years. Also, logic programming is well positioned to be the next big thing discovered by the web developers because of its relative obscurity and functional programming losing its mystery.

Give them a break. It is just one of the hundreds of hopeful toy projects posted here, of which only a handful that haven't been shot down within ten seconds.

You're right: it might be.

But it also might not.

And without him explaining the advantage of his approach, the project will be ignored by anyone who has used a system that shares his goal.

So, how do you describe how to install a package without looking like "scripting"?

Package { "bash": ensure => installed }

You describe the desired state in your met block, or more properly, tests meant to indicate if your desired state is met.

Your meet block is the scripting which is supposed to get you there, but which is considered fallible. The met block checks after to see if it actually worked.

> Quickstart

> Run the bootstrap script:

    bash -c "`curl https://raw.github.com/larsyencken/marelle/master/bootstrap.sh`"

PFHAHAHAHAHAHAHAHAHAHAHAHAHAHA

Ahm, that's the way to install pretty much everything these days.

I mean, I know it's a security risk. But it isn't any more (or less) of a risk than installing nvm or just running git clone.

No, it's not. I only see it on the odd hip-n-cool project by people with less experience than my server's uptime. Everything I install is either from a distro's package, from a tarball or by compiling from source.

I don't mind having a script that sets up the environment, there is a lot of software out there that does have these set up scripts in the tarball, or is distributed as a self-extracting archive, but you can always see it is marked as such. What I really balk at is "run this random script, trust me it installs". Would it kill them to write "download this script which will run apt-get pkg1 ... pkg10, then extract an inline tarball to ~/.local/lib"? I'm not going to run a random script that I have ZERO idea what it will do. It's not about security, it's about knowing that a good-intentioned non-compromised script won't crap all over my environment.

If you want to know what the script does, reading the script would be the obvious solution. Why should this program's author hold your hand and explain the script in prose when the script clearly explains itself already in its own language? The guy isn't demanding that you run it blindly. Maybe he figured anyone smart enough to write Prolog programs is smart enough to understand the implications of downloading and running a shell script.

It will be ok in most cases... until it won't. What this script does is install dependencies. And fails for anything that isn't the most popular system. I really don't see the point of writing a script like this, as opposed to the following text:

    Requirements: git, prolog (package swi-prolog-nox, or swi-prolog).
    To install checkout repository https://github.com/larsyencken/marelle and run "make install" (optionally with DESTDIR=/your/custom/destination/path).

Less writing, clear instructions and provided you know how to write a standard well-behaved makefile, it will also not assume surprising things about your system. Also they could ship the bin file without a static path in their repo instead of creating it on installation for some reason.

Those bootstrap files are really annoying me - also because they assume zero knowledge from the user (even if that user is supposed to later write system standup script in prolog... oh the irony). It also gets completely redundant sometimes - like the composer in php (https://getcomposer.org/installer) - it's a php script that includes loads of logic to download a single file and put it in the correct directory. And it's not an unusual case.

I really believe the bootstrap scripts are both useless and harmful, apart from a very few special cases.

Many of these scripts run on to pages, particularly if they attempt to cope with multiple systems. Tracing through what they do can be a real pain.

(My personal policy is that anything that asks to be installed this way does not get the script run as root, and does get its own uid, so that neither it nor anything it installs can read me uid. This does mean I'm stuck on an old version of rvm, since newer ones seem hell-bound to upgrade my apt infrastructure, and I've found no easy way for me to figure out what exactly it's trying to install, let alone what else it might do behind my back.)

That was the quickstart version—it's just being pragmatic. The alternative is to audit the setup script yourself, which is easy enough to do. You'd do the same for a tarball right?

If you trust the author and want to get started quicky it makes a lot of sense to simplify the install process to a one liner.

If you read the page, right under the quickstart script is the manual version describing all the same steps yourself. This indicates precisely what the script does, and leaves it to you to decide if you want to run it or just do the steps yourself.

Babushka not found

https://github.com/benhoskings/babushka

Looks like the repo has moved to a new Github account.

Not relevant to devops. Please change the title.

I'd like to hear your argument for this change. Seems apt to me.

Not sure what could be more relevant to devops than idiomatically updating state.

Reply on news.ycombinator.com