Adding links to system folders (the --system option)

[jdtcd]

Thought I'd mention my use of xpm in an educational setting. The context is a freshman university module that introduces students to the basics of microprocessor systems and computer architecture. The module is practical, using ARM assembly language and targeting an ARM Cortex-M development board.

I have used manually installed xPacks in the past but will be switching to xpm this year. This will give me a seamless way to support 250+ students using platforms of their choosing (mac/windows/linux). In particular, xpm will allow students to seamlessly (I hope!) work on their code across their own computers and our university computer labs.

One feature that is not yet implemented (#37 ) would be useful to allow our student computer labs to install shared packages that can be shared between the 100s of students who can share each lab computer. I have implemented a rudimentary for xpm that first looks for a required dependency in context.globalConfig.systemFolderPath and links to it if it exists, otherwise falling back to looking in context.globalConfig.globalFolderPath. This doesn't implement the --system option but instead relies on an admin manually installing the dependency packages in the correct location, which does not seem difficult.

Interested in any thoughts or feedback. Thanks @ilg-ul for your work on a great project.

[ilg-ul]

Thought I'd mention my use of xpm in an educational setting. ...

Oh, thank you for considering xpm to automate your setup in an educational setting.

This will give me a seamless way to support 250+ students using platforms of their choosing (mac/windows/linux). In particular, xpm will allow students to seamlessly (I hope!) work on their code across their own computers and our university computer labs.

Right, by design xPacks are expected to be cross platform.

... One feature that is not yet implemented (#37) would be useful to allow our student computer labs to install shared packages that can be shared between the 100s of students who can share each lab computer. ... the --system option ...

Hmmm... I completely ignored this use case, I thought it is a thing of the past. :-(

There are two aspects here:

• install in a system location
• adding links/shims in a folder part of the system path.

While I have several reasons to be cautious with adding the installed binaries to the system/user PATH, I don't think that there are reasons for not using a system location, so that all users will later link to it, and save a lot of space in multi-user systems.

I have to think about the details, and, if there are no drawbacks, try to implement it in the next release.

[jdtcd]

While I have several reasons to be cautious with adding the installed binaries to the system/user PATH, I don't think that there are reasons for not using a system location, so that all users will later link to it, and save a lot of space in multi-user systems.

Yes, installing seemed to me to be the hard/dangerous part, linking to already installed packs seems easier. For example, this change works for my scenario on macOS but I have yet to try it on Windows or Linux.

[ilg-ul]

At first sight your patch seems ok, please keep that branch alive for a while, until I have time to test and integrate it.

[ilg-ul]

As a preliminary step, I updated the folders used by xpm:

• https://xpack.github.io/web-preview/xpm/folders/

Any comments on this configuration?

[jdtcd]

This seems OK but that's based on my limited knowledge of the possible issues. The XPACKS_SYSTEM_CACHE_FOLDER assumes full implementation of the --system option to install xPacks, right? And is only needed for that?

Also worth me saying "if it ain't broke, don't fix it"! My use case of a shared user environment is easily handled by my fork of xpm and a manual copy/move of selected xPacks to a system location.

I think your concerns about installing binaries were well-founded. In particular, wouldn't it necessitate running xpm with sudo (or as an Administrator)? That seems to open up a whole world of issues. So, maybe a lighter-weight solution would suffice. And maybe that's what you have in mind.

[ilg-ul]

The XPACKS_SYSTEM_CACHE_FOLDER assumes full implementation of the --system option to install xPacks, right? And is only needed for that?

Right

I think your concerns about installing binaries were well-founded.

Actually not installing is problematic, but making the binaries automatically available in the PATH may add some unexpected issues; due to the multi-version design of xPacks, it is quite easy to loose track of what version is globally used. On traditional systems usually there is only one version, and normally system upgrades bring more recent releases, but with xPack you can install any previous version at any time.

So, maybe a lighter-weight solution would suffice. And maybe that's what you have in mind.

As you noticed, there are two issues:

• update install.js to create the links to the system location, if the desired version is there; for this your suggested patch is probably enough, or a good starting point anyway
• implement --system to unpack archives in a system wide location; this requires administrative rights and some care, but I think that the effort to implement it is reasonable

Since this issue was already on the TODO list, I'll try to implement it fully, hopefully these days.