# Why does the new Workbench plug-in not support the current Paclet format?

Posted 5 months ago
1406 Views
|
5 Replies
|
21 Total Likes
|
 I just downloaded Eclipse IDE and followed WRI's tutorial for installing the Workbench plug-in, which has been published recently in v10.2.40. Import of my existing project files, which were set up according to a workflow I had published on Mathematica Stack Exchange (see here) quickly showed that PacletInfo.wl files appeared to be (still) unknown to the plug-in.To verify this first observation, I created a new dummy project using the plug-in. And indeed the checkbox just lists PacletInfo.m and the file created upon its selection has the following content: (* Paclet Info File *) (* created 2022.07.01*) Paclet[ Name -> "DummyApplication", Version -> "0.0.1", WolframVersion -> "6+", Extensions -> { {"Documentation", Language -> "English"} }] So there is no PacletObject wrapped around an Association as is the current state of affairs in the Wolfram Language: Paclets Overview Tutorial.What are users supposed to do with a plug-in that only supports rather outdated formats? If you do not want us to program in the WL using an IDE, please say it frankly instead of in a round about fashion. ;-)
5 Replies
Sort By:
Posted 2 months ago
 Hi Guido,You are correct that, unfortunately, the Workbench has not been updated to support the modern PacletObject[<| ... |>] syntax for paclets. Our development efforts have instead been focused on improving the capabilities available in Wolfram Language itself for creating and developing paclets.For example, the DocumentationTools and PacletTools packages have undergone significant development over the last few WL versions, adding support for creating paclets and authoring and building documentation that previously was exclusively available in the Workbench. While the Workbench does have a few remaining capabilities that don't have a direct analog in WL, our work has focused on bringing WL up to par with and surpassing the Workbench.For example, as part of the recently released Wolfram Paclet Repository (https://paclets.com), we created a new Paclet Resource Definition Notebook tool that includes a GUI toolbar (see screenshot) for building documentation and privately or publicly sharing a paclet in the Wolfram Cloud, that additionally performs nice quality-of-life checks like linting for possible mistakes in your WL source code. If you're interested in these tools, you might also be interested in this ad hoc collection of links I've put together that points to some of the useful documentation and presentations we've done describing our work in this area:https://www.wolframcloud.com/obj/connorg/Published/Paclet_Development_Resources.nbI apologize for the issues you've had using the Workbench, but I hope that these new tools serve as a powerful and easy to use alternative. Work to improve and expand them is ongoing, so I would welcome any feedback you may have — please don't hesitate to reach out.Connor
Posted 2 months ago
 Hi Connor,Thank you for pointing me at those resources and indeed I often find myself drawn to the convenience of GUI tools.The main issue with regard to how I like developing code seems to be the fact that notebooks are "binaries" with regard to Git—and I can't see myself do anything without it. There is a reason to still stick to good old fashioned text input for programming as it does not "hide" anything and is nicely diff-able.While I certainly will give the "new" way of building Paclets a try, what would you advise with regard to Git?Thanks, Guido
Posted 2 months ago
 Saving notebooks in Git is not an entirely lost cause. There are a number of options you can disable to remove metadata from notebook files and make them easier to version-control. See, for example, the ResourceFunction SaveReadableNotebook:https://resources.wolframcloud.com/FunctionRepository/resources/SaveReadableNotebook/Evaluating the following lines in your notebook also helps a lot: SetOptions[InputNotebook[], PrivateNotebookOptions -> {"FileOutlineCache" -> False}]; SetOptions[InputNotebook[], "TrackCellChangeTimes" -> False] You can also remove the existing cell change timestamps in the Cell -> Notebook History... dialog.
Posted 2 months ago
 Hi Guido,I should clarify that the notebook GUI tools are simply buttons that call WL functions, and you can alternatively directly use the programmatic (textual) interface that the buttons are using if that's what you'd prefer.For example, you could create a Wolfram .wls script via: Aside: .wls scripts are plain text files, so you don't have to use the GUI button shown above to create one; the button is just convenient for generating the first line of boilerplate in the script. and save it to the root directory of your paclet folder, and add logic like: #!/usr/bin/env wolframscript Needs["PacletTools"]; (* Adjust as needed based on where your script file is located relative to your paclet. *) pacletRootDir = ParentDirectory[$InputFileName]; result = PacletBuild[pacletRootDir]; Print["Build result: ", result]; Then, when you wanted to run the script to build the paclet and its documentation, you could either click the "Run All Code" button at the top of the notebook:or run the script from the command-line by executing: $ ./build_my_paclet.wls (Note that for this second option, you'll need to have wolframscript installed on your PATH.Because the .wls script is just a plain text file, it should play nicely with being stored/diffed by Git in all the ways you expect.Using .wls script files is how I manage build steps in many of my WL projects, see e.g. scripts/BuildPaclet.wls in one of my GitHub projects.Let me know if this sounds like a useful approach to you, or if you have further questions.Connor
Posted 13 days ago
 Hi Connor,I currently use Dropbox as a PacletServer and (after switching from Windows to macOS) I have written the following little script for deployment of Paclets (I call it from .zsh where in .zshrc I defined a simple alias so that I can conveniently call it from anywhere by deploypaclet pacletdir. #!/usr/bin/env wolframscript (* read raw arguments *) $numArgs = Length @$ScriptCommandLine; $argWorkingDirectory = If[$numArgs >= 2, $ScriptCommandLine[[2]], Missing[] ];$argPacletServer = If[$numArgs >2 && DirectoryQ @$ScriptCommandLine[[3]], $ScriptCommandLine[[3]], Missing[] ]; (* create paclet archive *)$pacletWorkingDirectory = If[ DirectoryQ @ $argWorkingDirectory,$argWorkingDirectory, Echo["Paclet working directory not found."]; Quit[] ]; $defaultPacletServer = FileNameJoin @ {$HomeDirectory, "Dropbox", "PacletServerDirectory" }; (* or wherever *) $pacletSite = FileNameJoin @ { If[ MissingQ @$argPacletServer, $defaultPacletServer,$argPacletServer ], "Paclets" }; If[ CreatePacletArchive[ $pacletWorkingDirectory,$pacletSite ] === $Failed, Echo["Paclet archive could not be created at given site."]; Quit[] ]; (* build paclet site files *)$pacletServer = ParentDirectory[ $pacletSite ]; PacletManagerBuildPacletSiteFiles @$pacletServer; Print["Paclet deployed to ", \$pacletServer ] Another note: I just posted a question regarding the creation of larger Paclets with interdependencies here. It turns out that this works out nicely with Workbench/Eclipse and you can find the implementation for a function from the main package simply by pressing F3.I would greatly appreciate, if you guys could come back with more advice to people like me, who still prefer an integrated IDE like Eclipse for developing packages. :)