Timeline for How to provide latest paclet version
Current License: CC BY-SA 4.0
21 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 1, 2020 at 9:00 | history | edited | user21 | CC BY-SA 4.0 |
added 216 characters in body
|
Dec 19, 2019 at 9:28 | comment | added | user21 | @Kuba, excellent! And I have made it into the second example on the ref page ;-) You should advertise the hell out of this. | |
Dec 19, 2019 at 9:18 | comment | added | Chris K | @Kuba Works great -- thanks again! | |
Dec 19, 2019 at 8:20 | comment | added | Kuba | @ChrisK resources.wolframcloud.com/FunctionRepository/resources/… | |
Dec 16, 2019 at 9:46 | comment | added | Chris K | @Kuba Awesome, thanks! I owe you a beer or other drink of your choice :) | |
Dec 16, 2019 at 9:41 | comment | added | Kuba | @ChrisK I just did it with a stripped version of the MPMInstall and called it GitHubInstall. There is no point in pasting package contents to FR. I highly recommend to use MPM or PDInstallPaclet. This was my first, and last, submission so I don't know how long will it take. I will let you know. | |
Dec 16, 2019 at 9:36 | comment | added | Chris K | @Kuba Maybe you could submit it to the function repository to make it easiest to use? | |
Dec 16, 2019 at 9:33 | comment | added | Chris K | @b3m2a1 I feel ya about the function repository, but this might be a good case for an exception. It's sort of redundant to have to install a package to make it easier to install packages! | |
Dec 16, 2019 at 9:30 | comment | added | Kuba |
@ChrisK That is also what MPMInstall does :)
|
|
Dec 16, 2019 at 7:39 | comment | added | b3m2a1 |
@ChrisK that's what my PDInstallPaclet does (I wrote it to interface with packagedata.net originally). On the other hand, I refuse to contribute anything to the function repository on principle because I think it's a distraction and wasted time that could have been better spent elsewhere :)
|
|
Dec 14, 2019 at 6:02 | comment | added | user21 | @Chris K, might be doable. Give it a try. Though, I'd model the path part after FileNameJoin. | |
Dec 13, 2019 at 16:54 | comment | added | Chris K |
Thanks for the idea. It seems a bit redundant to have a separate ResourceFunction for every package though. Could we make a more generic GitHubInstall ResourceFunction that takes a github username and repo as arguments -- i.e. ResourceFunction["GitHubInstall"]["WolframResearch","FEMAddOns"] ?
|
|
Dec 13, 2019 at 16:30 | history | edited | user21 | CC BY-SA 4.0 |
added 43 characters in body
|
Dec 13, 2019 at 16:28 | comment | added | user21 | @murray, as mentioned there are two paclets that do this currently. These serve as presence I would argue. | |
Dec 13, 2019 at 15:36 | comment | added | murray | This certainly looks like the simplest approach - provided WRI accepts the resource function that does the installation. In general, files hosted at WRI seem to have had the greatest persistence over the years. | |
Dec 13, 2019 at 13:47 | comment | added | user21 | @Kuba, ah and a (+1) of course for your answer. Missed that in the first round.... Sorry. | |
Dec 13, 2019 at 13:44 | comment | added | user21 | @Kuba, yes you did. I felt that the convenience of this approach was not stressed enough, though and I thought I'd add an answer to do that ;-) Really, I think currently there is no better way to do this then this approach. | |
Dec 13, 2019 at 13:42 | history | edited | user21 | CC BY-SA 4.0 |
added 176 characters in body
|
Dec 13, 2019 at 13:34 | comment | added | Kuba | I did mention ResourceFunction for MaTeX :) To be clear, author needs to write and submit that function and in case of quick fixes any delay in approval can be stresfull. Anyway, your and Szabolcs' comments convinced me that this way deserves a separate section with pros and cons. | |
Dec 13, 2019 at 12:39 | history | edited | user21 | CC BY-SA 4.0 |
added 14 characters in body
|
Dec 13, 2019 at 12:33 | history | answered | user21 | CC BY-SA 4.0 |