# Install paclets into $BaseDirectory on multi-user system 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. • It should be possible as the paclet manager sources use both a $userRepositoryDir and a $sharedRepositoryDir. – Szabolcs Sep 5 '17 at 20:27 • You can Block the $userRepositoryDir with $BasePacletsDirectory/Repository. Worked for me. Although PacletFind freaks out a little bit and returns the paclet twice. – b3m2a1 Sep 5 '17 at 20:43 • Yep, I see that's what Kuba does too with WithPacletsRepository: github.com/kubaPod/MPM/blob/master/MPM/MPM.m – Szabolcs Sep 5 '17 at 20:49 • @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 :) – Kuba Sep 5 '17 at 22:09 ## 1 Answer 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 PacletManagerPackage$sharedRepositoryDir but this option is not exported. When you call PacletInstall it will call PacletManagerManagerPrivateinstallPacletFromFileOrURL 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 PacletManagerPackagePCrebuild. 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 PacletManagerPackage$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.
• One could run PacletDirectoryAdd in init.m for other locations. But so is with \$Path for custom directories. – Kuba Sep 6 '17 at 5:52
• @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. – halirutan Sep 6 '17 at 7:58
• 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. – Kuba Sep 6 '17 at 8:02
• @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.. – halirutan Sep 6 '17 at 8:09
• 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. – halirutan Sep 6 '17 at 8:12