4
$\begingroup$

Newbie starting to work with packages. I can create and load a package. However, when I come to update my package, I find the procedure very laborious. This is what I'm currently doing;

  • Update package in Mathematica front end and save.
  • Delete the current version at $UserBaseDirectory/Applications. (If I omit this step, the old version will not be overwritten by the new version despite the steps below.)

  • File/Install Package and point to updated source file.

    Needs["MyPackage`"]

Is there a simpler/more correct way of doing this as this seems very tedious, error-prone and frankly, incorrect? (The Update button in the front end doesn't seem to do anything other than update the list of functions)

Thanks in advance.

Improve this question
$\endgroup$
  • 1
    $\begingroup$ Are you using paclets? Here's a nice description of package/paclet development: mresources.github.io/tutorial/package-usage-and-development/… $\endgroup$ – Michael E2 Dec 5 '19 at 18:21
  • 1
    $\begingroup$ Long time ago I wrote a package that allows one to cleanly unload or reload a package under development. It is named "PackageManipulations" and available here. It comes with a notebook with examples illustrating its functionality. I have not tested it with recent versions of Mathematica, but I guess it should just work. Check it out, it might work for you. Also, you can simply add the location of your development version to $Path during development, and forget about $UserBaseDirectory/Applications. $\endgroup$ – Leonid Shifrin Dec 5 '19 at 22:00
  • 1
    $\begingroup$ From Leonid's suggestion- it sounds like your $Path modification didn't point to your package directory (FindFile gives a quick test to confirm). The "standard" way to packages uses WolframWorkbench (WW) that handles all the path manipulations automatically in testing and then as part of its "build" ports the package to the Applications folder. Installing WW at this point may be overkill though and at any rate, many developers prefer their own workflow; also, I believe there is some native package support on the way. Perhaps in the interim ... $\endgroup$ – Ronald Monson Dec 7 '19 at 11:34
  • 1
    $\begingroup$ ... one strategy might be to simply edit your .nb/.m/.wf file directly in the Applications folder. Alternatively, altering $Path should be pretty straightforward and you could then write a script to port/copy into the Applications folder when "building". $\endgroup$ – Ronald Monson Dec 7 '19 at 11:35
  • 1
    $\begingroup$ Using init.m is perfectly workable and traditional. Of late though, I find the persistence framework more natural for such settings (I don't have to remember where the init.m file is and can modify more seamlessly from a kernel session). You might want to have a look at Initialize,InitializationValue and friends for this purpose.On WW, If familiar with similar IDE's, IMO, it can be quickly useful (and even occasionally otherwise) but coming in cold, there are also (more?) advantages to building workflows in the front-end by harnessing its unique features. $\endgroup$ – Ronald Monson Dec 8 '19 at 0:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.