Group Abstract Group Abstract

Message Boards Message Boards

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

POSTED BY: Bianca Eifert
6 Replies
POSTED BY: Szabolcs Horvát

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

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

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

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
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard