Message Boards Message Boards

Is it a bad idea to move $UserBaseDirectory and share it between machines?

Hi everyone, I've got a bit of a whacky question. It's probably a terrible idea, but if nothing else, I was curious if I'm the only one wondering about this.

I'm tempted to mess with the MATHEMATICA_USERBASE environment variable, that is, change the location of UserBaseDirectory. My goal is to move it to my Dropbox and let it be used by multiple installations of Mathematica on multiple machines. BaseDirectory and InstallationDirectory would remain untouched and completely local to each machine, so I'm not asking about a portable installation. (Specifically, UserBaseDirectory/Licensing is empty.) I can see various problems with this plan, including:

  1. The folders "Paclets" and "Knowledgebase" seem more like temporary caches for automatically downloaded material and may not play well between machines.
  2. A similar concern holds true for things like code assist history files and other logging/history functionality.
  3. There may be even more fundamental clashes when multiple installations try to set up their UserBaseDirectory in the same place. I'm assuming that fresh installations or at least resets will be necessary, which wouldn't be a problem as long as it works.
  4. At some point down the road, I may be running different WL versions on different machines. Obvious problems ensue... or do they?
  5. If any file in UserBaseDirectory works with the actual path of that directory, I'd have to ensure that my local Dropbox folders have the same path on each machine. Not a deal breaker, but might be nice to know if anyone happens to have the information at hand.
  6. If none of the above is an issue, would things still go horribly wrong if more than one machine is running Mathematica at the same time? (Provided I'm not knowingly writing to the same file on both of them.)
  7. I'm ignoring possible privacy issues with commercial cloud providers, unless of course the ToS/License for Mathematica force me to care about that (which doesn't seem to be the case). Connectivity is also not a issue since all files exist locally even if they can't connect or sync to the cloud immediately.

My current approach is a Dropbox folder that contains selected folders from UserBaseDirectory, and a synchronization script to and from UserBaseDirectory. I don't dare sync the entire folder, for the same conflict concerns. It's a reasonable solution, and it's certainly safer. (Unless I forget to sync. Again.)

Does anyone have experience with a similar setup? Partial information would also be helpful, e.g. known issues when moving UserBaseDirectory at all (even on the same machine).

It would also be interesting to know if I can safely sync the entire UserBaseDirectory to Dropbox and back on multiple machines so that I'm nominally still working with the default location. (If that's the only or the safest way to make this work.)

I was sort of hoping that the UserBaseDirectory in the Wolfram Cloud would eventually be able to take on this task, but that doesn't look feasible right now unless I want to work with cloud-executed wolframscript exclusively.
POSTED BY: Bianca Eifert
6 Replies
Sort By:

Yes, built-in paclets seem to be the designated breaking point here. I haven't looked into paclets much at all (built-in or otherwise), I just noticed that you had played around with that for MaTeX (which btw is a great package).

I don't actually use Kernel/init.m to load anything, it just contains a few directory shortcuts that have no business living anywhere more permanently. My packages are mostly well-educated and know how to call each other when they need to, and what to do when their friends go missing.

Sadly, I don't have much time to play with any of this right now, but I know that you and possibly others are interested, so I'd post any findings here anyway, and I'll certainly find you if I have any revelations about paclets. (Don't hold your breath.)
POSTED BY: Bianca Eifert

Thanks for your thoughts on this!

Licenses are not an issue, they're in BaseDirectory already anyway.

I don't use a lot of LibraryLink stuff, but that's a good point to keep in mind.

Likewise, Paclets are something I mostly use unknowingly, that is, only when Mathematica uses them behind the scenes. I know you recently transitioned some of your packages to paclets, but I haven't looked into the pros and cons of that for myself. Good point though on the config files, I'd really have to ensure that my Dropbox folder is in the same location on all computers.

It's reassuring that you don't expect problems with items 3 and 4; those would be a real pain to mitigate.

At the moment I'm syncing Applications, Kernel (have a few lines of stuff in the init.m), and SystemFiles/Formats (recently started transitioning my import/export packages to registered import/export types and prefer the simplicity of that). However, just looking at some of the other directories: SystemFiles/FrontEnd is also a syncing candidate (I don't use palettes much, but that could always change). ApplicationData is another folder that I might actually use for its intended purpose of storing configurations and preferences for packages, with the obvious caveat that these are things I may want to set differently on different computers.

On the other hand, sharing packages with other people is obviously a lot easier if the contents that need to be installed are limited to the Applications folder; that's something many people will already know about, so an installation script wouldn't be necessary.

Still undecided... Knowing myself, I'll end up trying this at some point just for the fun of it, but realistically I'm probably better off selectively syncing. I'll certainly report back if I do try it though!
POSTED BY: Bianca Eifert

When I talked about paclets, I was thinking about the built-in stuff. That is one of the major things I worry may break. I wasn't referring to user-made paclets. I still haven't figured out most of the paclet stuff (any help is most welcome with that effort ... all this being undocumented I can't—actually don't want to—write to support when I get stuck).

I see that you have quite a few directories that you would like to sync. Personally, the only critical thing for me is the Autoload directory, which I keep in a git repo. Of course, git won't synchronize automatically, but that may even be a good thing in some cases. To be honest, I did plan for synchronizing multiple machines at some point, but I haven't gotten around to doing it properly yet, so I can't comment on how effective this is.

I use Autoload instead of Kernel/init.m because it affects subkernels as well as the main kernel.

I would like to know how your experiment goes. Please keep us updated!
POSTED BY: Szabolcs Horvát

BTW with palettes it is possible to place them into 

Applications/MyApp/FrontEnd/Palettes

and they will show up in the Palettes menu.

It would be nice to investigate if it is possible to do the same with the Formats directory. 

Applications/MyApp/Formats

This would reduce the number of directories that need to be synced and would allow you to structure the importers/exporters nicely into applications. If you do try this out, let me know how it went! Unfortunately I don't have time to try this right now.

There are many special directories within applications, e.g. LibraryResources/$SystemID gets added to the $LibraryPath automatically.

Yet another thing to investigate later is what sorts of "extensions" to add to a PacletInfo.m in order to allow the relevant directory to integrate into the system. Is there a "Formats" extension? But at this point I'm starting to stary off-topic ...
POSTED BY: Szabolcs Horvát

I just tried copying the Formats folder to Applications/importstuff/Formats (with a basically empty importstuff.m file to establish the context), that didn't work. You can however simply copy the actual code for RegisterImport and the import converter into a package in the app's directory and that will do the trick just fine. You obviously have to load the package before you can use Import with the new format, so that's a bit counterintuitive.

The FrontEnd folder inside a package works, and it makes sense for larger apps. But again, if you have something that's basically a stand-alone palette and wouldn't need a package for anything, things get counterintiutive.

Interesting point about the extensions in PacletInfo... Those are a little bit, erm, under-documented, so I'm not aware of a solution for formats. I'm still a bit torn about RegisterImport on the whole, but that's a different can of worms.
POSTED BY: Bianca Eifert

What could cause problems in principle?

Licenses: There would be a problem with the license because $MachineID is different. Either put several licenses in the same mathpass file or put them in $BaseDirectory. I haven't tried either, but I assume it would work.

Paclet stuff: Are there any configuration or other files which contain absolute paths and would break when moved? I grepped my user base directory, and found many absolute paths in Paclets/Configuration/pacletData...pmd2 files. Didn't find anything else which seemed relevant.

LibraryLink stuff: Shared libraries compiled on one machine may not work on another. But this shouldn't really be a problem. Just make a package if you want to keep re-using the same binaries.

Your concerns—are there problems? These are my guesses:

  1. Yes, see above. 2. It's not clear to me that there would be any problems. 3-4. I don't expect problems. I always have multiple versions installed on the same machine. Check Preferences -> System -> Create and maintain version specific preferences. 5. See my comments above. 6-7. Don't know.

What exactly are you synchronizing now beyond Applications?
POSTED BY: Szabolcs Horvát
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract