Is asdf breaking openfnx?

[josephjclark]

If you run pnpm install:openfnx inside kit (and where else would you run it?) it'll install openfnx to the asdf context (version shim) associated with that folder.

If you then step out of kit and run openfnx, you MIGHT be calling the bin from a different asdf context, ifyou've got a global version set or a tool-versions or something.

Even worse, it might be that the different builds are reporting the same branch names. Certainly the output I just saw in mtuchi's log looked good. This is what he saw in his water-aid repo:

  water-aid git:(main) ✗ openfnx version
[CLI] ♦ Versions:
         ▸ node.js     18.12.1
         ▸ cli         branch/cli-cache
         ▸ runtime     ./openfn-runtime-1.1.1-local.tgz
         ▸ compiler    ./openfn-compiler-0.1.1-local.tgz

It looks fine! And yet behaved wrongly. I note that its using node 18.12 there, which is actually the same as what kit uses.

So I don't know. Maybe this is nothing. I need to do a few tests on my own machine and try to work this out.

I would like to ensure that install:openfnx registers the openfnx bin to some global place outside of asdf's reach. I want only one openfnx on the system. That may be impossible - the face is that asdf and any version manager is basically going to override whatever local config I set in kit. That's kind of the point.

[josephjclark]

Troubleshooting: installing openfnx from kit will install to whatever node version kit is set to (18 at the time of writing).

If you run openfnx from a different dir (and of course you will), it'll look in the global npm install for that local version. If it matches kit you're all good, if you've set the global or local verison differently, openfnx won't be available.

Possible solutions:

• set asdf to kit's version in that local folder asdf local 18.12.11 (or whatever it is right now)
• Try and find a way to globally install openfn outside of asdf. I don't even know what this means. But if the bin is not registered to node's global bin dir, but instead registered elsewhere on your system, or even aliased, then it should always work.
• when running installl:openfnx in kit, allow a custom node version as an argument. This doesn't help much.

The idea of different openfnx verisons sitting in different node installs is frankly a bit scary.

Also how does any of this work in windows?

[josephjclark]

I am pretty sure that this is just that asdf has several global node versions and openfnx just installs to one of them. Dirs with different asdf contexts will use a different globals folder and may not find openfnx (or worse, the wrong one)

What we want is to somehow "breakout" the openfnx command so that it is not tracked by asdf. I want to use a global build of the openfnx bin against whatever node version is set in the working dir.

[josephjclark]

See #653 maybe

[josephjclark]

A clear take on the problem and solutions.

Building openfnx from kit will build and install openfnx to the global node environment of kit's node version, because the build process uses npm install -g path/to/cli.

When you use openfnx from another directory, whether openfnx is available depends on the node version available in the directory. If you're using openfn on the system than chances are you're using a different global/default node version than what kit uses. And so openfnx isn't available.

What users must do today is set their local node version to match kit, with asdf local nodejs 18.17.1 or whatever. Now that folder will find openfnx. You can of course set the global nodejs version to match kit.

The only fix we can really do from kit is to create (or tell users to create) an alias in their environment for openfnx. If we do:

alias openfnx=~/.asdf/installs/nodejs/18.17.1/bin/openfn

Where most of the that path is the result of calling node -g from inside kit, then we've set up an alias on the system which will bypass asdf entirely, and explicitly run the openfnx bin from anywhere on the system. Ideally we could set this up automatically but it does depend on your system and its some install faff I don't want to get stuck into. Better to invite users to set it up.

When running openfnx like this, users will use whatever node version is set in that folder./environment. So the runtime node version would be different to the build-time version.

But! When testing locally, the openfn --version from my root and from my kit repos both report different version numbers. One reports the prod version number, the other reports the branch name. This surely is a bug in the openfnx build? Like it's path resolution isn't robust enough