13
$\begingroup$

PacletInstall will install paclets into the $UserBaseDirectory by default. How can we install them in $BaseDirectory so that all users on the system will have access? Is this currently possible?

This is an important consideration if your package is expected to be installed on centrally managed multi-user systems (e.g. HPC clusters). This is not merely a theoretical situation. I know that MATLink was installed this way on more than one site.

Update: It is not clear that system-wide paclets are well supported at this moment, even though the basics seem present in the paclet manager. My conclusion is that at this moment it is better to avoid using paclets for system-wide installations.

Improve this question
$\endgroup$
4
  • $\begingroup$ It should be possible as the paclet manager sources use both a $userRepositoryDir and a $sharedRepositoryDir. $\endgroup$
    – Szabolcs
    Sep 5, 2017 at 20:27
  • $\begingroup$ You can Block the $userRepositoryDir with $BasePacletsDirectory/Repository. Worked for me. Although PacletFind freaks out a little bit and returns the paclet twice. $\endgroup$
    – b3m2a1
    Sep 5, 2017 at 20:43
  • $\begingroup$ Yep, I see that's what Kuba does too with WithPacletsRepository: github.com/kubaPod/MPM/blob/master/MPM/MPM.m $\endgroup$
    – Szabolcs
    Sep 5, 2017 at 20:49
  • $\begingroup$ @b3m2a1 and Szabolcs, yes but so far I didn't have problems with this and Get or PacletInformation respect the most specific repository at the end. Otoh I won't bet my hand on that :) $\endgroup$
    – Kuba ♦
    Sep 5, 2017 at 22:09

2 Answers 2

Reset to default
8
$\begingroup$

As I've pointed out here, on Linux it might be problematic to simply Block the $userRepositoryDir as you will need root-access for that in the default installation. No matter how you do this, you need to ensure that you can write there if you want to make it consistently working for all operating systems.

To the best of my knowledge, there is currently no easy way to install a paclet for all users automatically. What you want is to install a paclet in the PacletManager`Package`$sharedRepositoryDir but this option is not exported. When you call PacletInstall it will call PacletManager`Manager`Private`installPacletFromFileOrURL and there, the installation destination is hard-coded to $userRepositoryDir.

This is why Blocking this kind of works. I say "kind of" because after the paclet is unzipped into the destination, Mathematica rebuilds the internal information about installed paclets by calling PacletManager`Package`PCrebuild. If your destination is anything other than $userRepositoryDir or $sharedRepositoryDir, this shouldn't work, because the paclets to rebuild are again hard-coded as "Collections" -> {"User"}. Please look at the end of the definition of installPacletFromFileOrURL.

Therefore, the only sensible solution I see at the moment is

  1. Check if you have write access to PacletManager`Package`$sharedRepositoryDir. If not, and you are on Linux, you might want to ask the user to re-run Mathematica with sudo.
  2. Block the $userRepositoryDir as suggest by b3m2a1 and already used by Kuba.
Improve this answer
$\endgroup$
8
  • $\begingroup$ One could run PacletDirectoryAdd in init.m for other locations. But so is with $Path for custom directories. $\endgroup$
    – Kuba ♦
    Sep 6, 2017 at 5:52
  • $\begingroup$ @Kuba Hmm, it's not clear to me what the side-effects are, but directories added with PacletDirectoryAdd go into the "Extra" paclet collection, while the ones installed with PacletInstall are stored in the "User" section. $\endgroup$
    – halirutan ♦
    Sep 6, 2017 at 7:58
  • $\begingroup$ I don't know either but do you anticipate problems? I use PacletDirectoryAdd for testing/running paclets directly from their development directories. So far didn;t have problems even if released versions where already PacletInstall-ed. $\endgroup$
    – Kuba ♦
    Sep 6, 2017 at 8:02
  • $\begingroup$ @Kuba When I see this right, Szabocls wants users to easily install his package with PacletInstall which is convenient since he can do this directly from the GitHub repo. If he does this, then the version is of the paclet is tracked in the "User" collection. If a different user opens the same Mathematica, he uses his own User-collection which has no idea about the installed paclet. When I see this right from looking at the code then a) the user that installed the Paclet (in a different dir with Block) has it tracked in "User". If he runs PacletDirectoryAdd that it is probably tracked.. $\endgroup$
    – halirutan ♦
    Sep 6, 2017 at 8:09
  • $\begingroup$ twice. b) a different user who is opening the same Mathematica can use PacletDirectoryAdd. As I said, I'm not sure if there are any serious consequences. I merely point out that there are some glitches that might lead to weird behavior and one should look out them or intensively test the approach. $\endgroup$
    – halirutan ♦
    Sep 6, 2017 at 8:12
1
$\begingroup$

I faced similar issues, so i switched to the NPM like way of organising paclets.

Wolfram Local Packages Manager

So it stores everything in the projects’s folder and keeps all paclets up to date according to github repos. That helped me a lot, since there is no need to guess if PacletInstall will figure out a new version.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.