Ticket #35 (closed enhancement: fixed)

Opened 6 months ago

Last modified 3 months ago

Provide a per-user directory for CustomResult classes, etc.

Reported by: kaiw Assigned to:
Priority: low Keywords:
Cc:

Description

When reinteract is installed system-wide, it is nice to be able to store utility files, particularly things like CustomResult? classes, in a per-user directory. This patch accomplishes this in a (probably overly-)simple way, using ~/.reinteract and prepending it to sys.path.

Attachments

0001-Add-.reinteract-as-a-user-specific-path-for-reintera.patch (0.8 kB) - added by kaiw on 06/10/08 17:53:55.
Patch
Support-reinteract-specific-plugin-directory.patch (508 bytes) - added by kaiw on 09/02/08 11:09:34.
Patch

Change History

06/10/08 17:53:55 changed by kaiw

  • attachment 0001-Add-.reinteract-as-a-user-specific-path-for-reintera.patch added.

Patch

08/10/08 23:55:41 changed by otaylor

Hmm, need to think about this a bit. I'm not sure a dot-directory makes sense since it would be a directory where the user is going to be editing files. And I think dot-directories should be reserved for things that are "behind the scenes". But just creating a ~/reinteract directory in the users home directory would likely get people angry.

Perhaps the simple solution is to just make a config option for directories to search for imports. But that then means figuring out how I want to do config options.

08/13/08 10:48:39 changed by kaiw

I see your point, but I don't think that people will necessarily be editing these files. In a longer-term perspective, it's conceivable that you might want to have plugin-like capabilities for reinteract, and 'normal' users don't edit plugins.

A use case might be: trying to get scientists to use reinteract instead of matlab, etc. For example, I know people who use the python NetworkX package to do research, and I have a CustomResult? for the networks it produces... but to the people using the CustomResult?, it's just a renderer. Essentially, I'm arguing that some of reinteract's target audience might be of the 'inexpert coder' variety.

Having said this, I think that the config option for an import directory is also a good solution, as it covers the general use case of 'support files for using reinteract'.

08/13/08 20:14:07 changed by otaylor

Hmm, the plugin analogy is a good one. If you submit another patch that:

A) Doesn't mkdir the directory if it doesn't exist (that's going to be annoying on windows

where . files aren't hidden)

B) Uses ~/.reinteract/modules (~/.reinteract/python?) instead of the plain ~/.reinteract

I'll commit it.

09/02/08 09:13:19 changed by kaiw

Patch updated to current master.

I considering using the new GlobalSettings?, but as the location of a plugin directory doesn't really seem like something that needs to be configurable, I left the patch as-is.

09/02/08 10:27:30 changed by otaylor

Doesn't this need to be higher up in the file? With where it is currently, I don't think specifying a worksheet on the command line will work, since it will be loaded (and calculated) before sys.path[] is adjusted.

09/02/08 11:09:34 changed by kaiw

  • attachment Support-reinteract-specific-plugin-directory.patch added.

Patch

09/02/08 11:11:00 changed by kaiw

Yes, sorry about that. I only tested the patch by opening worksheets from within the application. Updated.

09/02/08 18:53:16 changed by otaylor

  • status changed from new to closed.
  • resolution set to fixed.

Patch committed to master:

http://git.fishsoup.net/cgit/reinteract/commit/?id=d8aee80457abefe2d25fa5aaec17e89ab9b9f46e

After I merge the notebooks branch, I need to add some sort of memory of "what notebook was last open" to reinteract, so that will probably mean adding a file like ~/.reinteract/state or ~/.reinteract/config on Linux. On Windows, that will go in the %LOCAL_APPDATA%/Reinteract directory; so when I do that I might move the modules directory to %APPDATA%/Reinteract/modules.

Thanks!