10

Mathematica has a simple package manager in the PacletManager and I've been working recently on getting my code to be more easily distributable through it, going so far as to write a package to build a paclet server with it's own static site in the cloud (it's free, so why not?) (or you can also use GitHub)

The best part of this is that not only is it to install package from a paclet server, it's also pretty easy to see what's on a paclet server and if other people used them I'd be happy to build a GUI that would list all the packages on a server with download / update buttons, etc.

So how do we convince people to distribute their packages as paclets on paclet servers? Are people doing this already and I just never got the memo? Or is this just too much work for the average user? At this point I've got frameworks in place to make this all quite easy, if people don't mind using junk from a suspicious person like me. But it's truly not that hard to do by hand anyway, once you know what you have to do.


Update:

Kuba suggested I share the framework I've been developing for this kind of stuff. I wanted to add some tweaks to it so I'm just getting it up now, but it's here. It's spawned off of a more expansive package, BTools, so it shares documentation with that. You can look at that here. The package supports making sites and docs like that. It also supports building paclet servers like this, which is why it's even worth mentioning here at all. If people want to use it, but can't figure out how, I'm happy to debug, extend, add palettes, etc.


Update 2:

If you're happy enough setting up for PacletInfo.m files and CloudDeploy-ing stuff yourself here's a simple way to do that.

Given a package, MyPack, which, e.g., looks like this:

MyPack
 MyPack.m
 + Kernel
   -init.m
 etc.
 PacletInfo.m

You can turn that into a paclet file with:

PacletManager`PackPaclet["path/to/MyPack"]

Then you can put that in a directory, say e.g. PacletServer, that looks like this:

PacletServer
  + Paclets
    - paclet_1
    - paclet_2
    - paclet_3
    ...

You can build the PacletSite.mz file for that using:

PacletManager`Package`BuildPacletSiteFiles["path/to/PacletServer"]

Then put that in the cloud like this:

CopyFile[#,
 CloudObject[FileNameDrop[#,FileNameDepth["path/to/PacletServer"]-1],
  Permissions->"Public"
  ]
 ]&/@Select[FileNames["*","path/to/PacletServer",Infinity],Not@*FileExistsQ]

These three steps are all it takes to build a paclet server. My stuff just makes it a bit easier to extend this.


See Also:

21
  • 7
    I guess the best way is to show that it is easy and works. Along with minimal 'how to' and guide to PM. It should be clear what it does and what it can't do (yet). Why aren't people already using PM and paclet servers? I suppose because there isn't any official documentation/support. If you are a insert specific scientific field geek you don't really want to waste time on experimenting with undocumented framework which additionally can change without notice.
    – Kuba Mod
    Aug 30, 2017 at 7:51
  • @Kuba do you think it's worth writing some PM tutorials as I use it? I think the fact that WRI itself distributes code through it is a pretty strong vote in favor of the core functionality staying the same, although I guess one would have to ask Todd Gayley about that.
    – b3m2a1
    Aug 30, 2017 at 7:56
  • I think so. From what I've asked him, it should stay at least backward compatible as it is indeed used internally. Bug/issues fixes and upgrades will be made tough.
    – Kuba Mod
    Aug 30, 2017 at 7:59
  • @Kuba if I do write some tutorials on using it, do you think it's better to write them as documentation-style tutorials and host those pages and their source notebooks in the cloud or as Q/A's?
    – b3m2a1
    Aug 30, 2017 at 8:04
  • 1
    Don't know about full documentation but this minimal 'how to' should fit readme.md on your framework github repository.
    – Kuba Mod
    Aug 30, 2017 at 8:07
  • @Kuba sounds good. I'll get to that in a little while, because I have documentation that will be building for the next few hours and which essentially locks the front-end when it does.
    – b3m2a1
    Aug 30, 2017 at 8:10
  • 7
    For one, it would help if I wouldn't get replies from [email protected] that read: "As I understand, you ran into a problem with the PackPaclet command. While we make no guarantees regarding the behavior of undocumented functionality, it does seem as though the Verbose option here doesn't seem fully implemented. I can file a report regarding this to bring this to our developers attention, but cannot guarantee that it will be highly prioritized, again because the functionality is undocumented."
    – halirutan Mod
    Aug 30, 2017 at 11:39
  • 9
    "How do we get more people to use paclets?" It's Wolfram's responsibility to implement, document, and popularize a package manager, not ours. It's also their responsibility to support and encourage third-party package development through providing tools and education. Sadly, this doesn't really seem to be a priority for them.
    – Szabolcs
    Aug 30, 2017 at 12:01
  • 7
    Mathematica is excellent as an interactive environment. End-users are well supported by Wolfram. But (package) developers are not. This is worrying because of course Wolfram theselves do the most Mathematica development internally, and I can't imagine that the lack of good dev resources doesn't affect them too. A good package ecosystem is also going to be critical for Mathematica's long-term survival.
    – Szabolcs
    Aug 30, 2017 at 12:03
  • 4
    @Szabolcs what stage are you? I think I'm almost 5. So, of course it is theirs job, but it wasn't / is the priority to whoever decides what is a priority. Serious users weren't silent about that need, they are just ignored for years. Don't want to blame developers, they are always helpful and usually just don't have time for that.
    – Kuba Mod
    Aug 30, 2017 at 13:02
  • 3
    @Szabolcs I know this isn't something we should have to do and also that it'd be so much better if WRI would just take some time to create a proper centralized package repository / manager. In the meantime though I think if outside people start to use the systems they have built, it might get a bit more traction on the issue. At the very least it'll show there are people in the community who care enough to use them.
    – b3m2a1
    Aug 30, 2017 at 15:29
  • @Kuba I finally got the stuff up. Take a look at it when you have time, send me suggestions, etc, blah blah.
    – b3m2a1
    Aug 31, 2017 at 3:00
  • @b3m2a1 will try to look at it but can't promise anything, e.g. can't test it on daily basis as almost always my work requires far more complicated setup than whatever is considered a paclet/package. So incorporating it will probably need a lot of teaks which I can't afford now. But I will try to use it for side projects.
    – Kuba Mod
    Sep 1, 2017 at 12:01
  • @Kuba cool. My main hope is that it minimally simplifies using the PacletManager itself. But the PacletManager isn't too hard to use anyway. Maybe I'll write a quick note on that too.
    – b3m2a1
    Sep 1, 2017 at 16:05
  • About paclet sites: I am not fully comfortable using them just yet. You would be taking on a big security responsibility because of silent updates. There is also greater potential for messing up things with the paclet site management functions. You have to assume that if something can be messed up, someone definitely will, and then will complain about it. What if someone removes the default paclet site?
    – Szabolcs
    Sep 5, 2017 at 18:44

0

You must log in to answer this question.

Browse other questions tagged .