I'm developing a package that has been released, but every week or every few weeks there are new features added to the core version.
What I'd like to do is to notify users that new features are available such as
julia> using Package
Note: new features are available:
- feature 1
- feature 2
call Pkg.update("Package") to make these features available
Is there a standard/built-in way of doing this? I'd rather not make the users have to install the Requests and LibCurl packages for this single feature.
There is a built-in command to download a file, download. You could download the next three possible release numbers from GitHub:
for version in [v"0.4.1", v"0.5.0", v"1.0.0"]
filename = download("https://github.com/JuliaFinance/Currencies.jl/releases/tag/v$version")
data = readstring(filename)
if data != """{"error":"Not Found"}"""
println("Version v$version is available!")
# this release was tagged on GitHub, notify user
end
end
Probably this will only work if you tag your versions on GitHub. You should probably hide this all in a try...catch and suppress any errors, so the lack of Internet connection does not affect users' ability to use the package.
Related
I've created an R package and I'd like to upload it to CRAN via GitHub Actions whenever I merge changes into the master branch. I've found a lot of examples of R actions and I've even looked up how some of the most popular packages like dplyr do it and even though I've found a devtools::release() helper function, I still haven't seen a workflow that would submit a library to CRAN when you merge changes into the master branch. Do package developers do this manually? Is there any reason why this hasn't been automated?
CRAN works quite differently from other language repositories, as uploads are not fully automated like in e.g. PyPI.
When you upload a new package, it is subject to verification from an actual human. When you update a package, if it triggers certain checks it will also be subject to a new review from a human. When a package uploads successfully and passes the first verification, many automated checks are run for it over the course of weeks (e.g. different OSes, compilers, compiler options, architectures, sanitizers, valgrind, etc.), and precompiled binaries are automatically generated for some platforms and R versions from your source code.
The CRAN policies explicitly state that frequent updates are not allowed, and you're not supposed to be submitting uploads any faster than once every couple months, for which I think this level of automation would not be worth it.
Even if you do want to automate this process, there is an email verification in the middle, so you'd perhaps have to do something with selenium + other scripts.
BTW if you are worried about complicated building processes and are using RStudio, you can configure on a per-project basis what arguments to use when building source or binary distributions of your package.
I am developing an R package that will not be hosted on GitHub or submitted to CRAN. I am using git for version control. I would like to give my users the ability to load older versions of the package. I've read here about usethis::use_version() for versioning my package. This will track the versions using git, but I'm wondering if there's a straightforward way for my end users to load an older version without having to use git themselves. For packages hosted on CRAN, I know the versions package can be used to achieve this.
Right now my best solution is to create a copy of the R package in a new directory when starting work on a new version. Then the end users can load the version they want by choosing the appropriate directory. If there is a better solutions than this, I would be interested to hear it.
The remotes::install_git() function has a ref= parameter when you type a commit or tag name. If you tag your releases, then you can install which ever version you want with the correct tag. Your users don't need to run git themselves, but they will need access to the git repo to pull the correct version.
If you want to host your own repository for your users, you can also look into something like miniCRAN or drat. Since those basically a CRAN-like repository for your packages, you can probably use existing tools like the versions package to interact with the repo (assuming you keep older versions around in the same way CRAN does).
Due to recent experience with several bugs created by updating packages, I wonder what the best approach is for the following problem:
I currently provide a stand alone version so to say of my shiny App (just the script files to run it locally) and run a long list of require() functions to load / install the needed packages. However, in the end I would like to use fixed package versions to avoid bugs created by changes in packages.
Is there a way to ensure that the user, who may have older or newer versions of packages on their computer, is using the right version of all the packages my app needs?
You can consider using packrat: https://rstudio.github.io/packrat/.
Unfortunately, private libraries don’t travel well; like all R
libraries, their contents are compiled for your specific machine
architecture, operating system, and R version. Packrat lets you
snapshot the state of your private library, which saves to your
project directory whatever information packrat needs to be able to
recreate that same private library on another machine.
Short tutorial:
RStudio - File - New Project - New Directory - New Project - "Do: use Path" - Create Project
Enter in the R(Studio) console:
Code:
packrat::init()
.libPaths() # test if libpath has changed
install.packages("reshape2") # installs within one of the packrat libpaths
Installing package into ‘C:/R/packRatTest/packrat/lib/x86_64-w64-mingw32/3.4.3’
Assumption would be that you can use and share RStudio Projects, but i think it would be hard to work without them anyway ;).
Try writing your shiny app as a package. You can, somewhat, control that through the description file.
Since you said you're using script take a look at: https://github.com/chasemc/electricShine
Even of you don't use it, hopefully looking at the code will help for things like setting the download repo to be a specific MRAN date.
I'm building an Rmarkdown document reliant on a frequently updated data package that's hosted on github.
How do I make sure that the document is always built using the latest version of the package, without installing the package on each build?
You can see the list of commits to a package by getting the commits page for the package. For example,
https://github.com/tidyverse/dplyr/commits
shows that there were commits today. If you save a copy of the top hash in that response (currently af75177), and then update whenever it changes, you should be sure to have the latest version.
However, this is likely a bad policy. The package is not necessarily in a working condition after a commit: perhaps the author is planning another one a minute later to finish some update. It's much safer to use update.packages() and only get the updates that are judged to be stable enough to be sent to and accepted on CRAN.
I'm creating a fairly straightforward offline installer for my product using the Qt Installer Framework (v3.0).
The product includes a driver installer for a Sentinel HASP protection key. Ideally I would like to present the user with an option to skip running this driver installer (in the case where they have already installed this driver with a previous product installation, for example), but I can't seem to find a concise example in the QtIFW documentation of the best/simplest way to achieve this.
The size of the driver is relatively tiny compared to the size of the main product package, so there's no concern with always including the file.
Let we have driver-installer.exe that installs that driver.
If you want to make its execution optional you can add failed return code as accepted return code for this execution like below
component.addOperation("Execute", {0,xxx}, "driver-installer.exe");
Here xxx should be replaced with your failed return code