I have a package that I developed to enable my team (and perhaps other interested users) to install and use a particular R package (RQDA) that was archived on CRAN. I have hosted this package on GitHub and am trying to set up GitHub Actions so that I have a CI workflow in place.
Whenever I run R CMD check locally everything is fine, but when I push to GitHub the build fails. This is because, by default, Actions tries to install that same (archived) package. Expectedly, this fails.
So, my question is this: is there a way I can disable the check for a specific package dependency? There are no plans to ever send this package to CRAN, so I am happy to bypass their package policy in this instance.
2 possible ways:
Upload the source for RQDA to a Github repo, or other publicly accessible location, and put a Remotes: line in your DESCRIPTION file
Save the package to cloud storage, eg an S3 bucket or Azure storage container, and download it from there as a separate workflow step prior to checking
This is how I was able to deal with the problem:
The changes made were entirely in the workflow file at ./.github/workflows/. One of the jobs there is for installing R package dependencies for the project:
- name: Install dependencies
run: |
remotes::install_deps(dependencies = TRUE)
remotes::install_cran("rcmdcheck")
shell: Rscript {0}
The first thing I did was to change the dependencies argument to NA so that only packages listed in Depends and Imports are installed. (The RQDA dependency that was giving me trouble is under Suggests).
There was still an error but this time with some guidance that involved going to the job Check and setting the environment variable _R_CHECK_FORCE_SUGGESTS_ to false.
The check now works as expected.
Related
I will let an R project run on a data center and the team working there has no access to the Internet, so they will have to download the R libraries from an internal repository (on their Intranet) where all the packages are hosted.
It is possible to change the repository from where the libraries are downloaded?
and how can we point to this repository if I will provide them with my renv.lock file?
Could be solved by doing this? :
repos <- c(CRAN = "https://cloud.r-project.org", WORK = "https://work.example.org")
options(repos = repos)
See here
Thanks a lot
It is possible to change the repository from where the libraries are downloaded?
Yes, and the example code you shared is correct: the active package repositories used in an R session are controlled via the repos option.
and how can we point to this repository if I will provide them with my renv.lock file?
If you're working within an renv project with an auto-loader, then renv will automatically set the repositories from the lockfile when R is started. Otherwise, you can call renv::load("/path/to/project") to explicitly load a project at some location.
I'd recommend reading https://rstudio.github.io/renv/articles/renv.html for more details.
I found myself in the situation where my private repos were set, but whenever I ran renv::init(), it wouldn't point to them. The simplest solution I could come up with from reading the renv docs:
Before calling renv::init(), call the function: Sys.getenv("RENV_CONFIG_REPOS_OVERRIDE").
If it returns anything other than the URL to your private package repository then call the function: Sys.setenv("RENV_CONFIG_REPOS_OVERRIDE" = "your_private_package_repository_url")
Call the function renv::init()
I want to be able to import or using a package that I'm writing in a directory ~/projects/ExamplePkg from my main Julia REPL / from another project or environment.
By ]foo I mean "use the foo command at the Julia Pkg REPL". Type ] at the Julia REPL to enter the Pkg REPL. Use ]help <command name> for more info or check the link below.
Ensure that your package has a Project.toml that gives it a UUID and names it (generate one with ]generate from the Julia REPL or with the PkgTemplates package) and that it is in a git repo with at least one commit including all the relevant files.
Then choose how you would like to use the package.
You probably want to run ]dev ~/projects/ExamplePkg:
If dev is used on a local path, that path to that package is recorded and used when loading that package. The path will be recorded relative to the project file, unless it is given as an absolute path.
If you use dev and you change the dependencies in the dev'd package, then you should probably run ]resolve in all environments that depend on the package.
Or you can run ]add ~/projects/ExamplePkg:
Instead of giving a URL of a git repo to add we could instead have given a local path to a git repo. This works similarly to adding a URL. The local repository will be tracked (at some branch) and updates from that local repo are pulled when packages are updated. Note that changes to files in the local package repository will not immediately be reflected when loading that package. The changes would have to be committed and the packages updated in order to pull in the changes.
In Julia versions <1.4: If you accidentally ]add a package before the git repo is set up correctly then you might get ERROR: GitError(Code:EUNBORNBRANCH, Class:Reference, reference 'refs/heads/master' not found). Unfortunately, Julia will probably have cached the bad repo, and you will need to remove that from ~/.julia/clones/<gibberish>/. You can find the dir to remove with grep: $ grep ExamplePkg ~/.julia/clones/*/config.
Documentation: https://julialang.github.io/Pkg.jl/v1/managing-packages/
you can try
path_to_package = "~/projects/ExamplePkg"
push!(LOAD_PATH,path_to_package)
# then use it, ExamplePkg is the package's name
using ExamplePkg
But you have to run codes above whenever you restart Julia.
reference is Workflow tips-Julia Documentation
I often ]dev Pkg but I want the devved packaged to be stored somewhere other than the default location for convenient access.
I don't want to change the path of the ]add Pkg. This seems to be controlled by the environment parameter DEPOT_PATH.
Is there a way to change only the path for dev Pkg, i.e. the path in which the dev package is stored?
You can set the environment variable JULIA_PKG_DEVDIR to change where development packages are installed. See the develop docs for more info.
As #crstnbr noted, an alternative is to use the --local option to the pkg> dev command to install a development version of the package in a dev directory within the current project. This could make sense if you're developing your own package MyCode.jl which relies on Example.jl and you need to make a hot fix to Example.jl. Then your Pkg REPL command would look like this:
(MyCode) pkg> dev --local Example
If you would like to make changes to a third-party package and submit those changes as a pull request on Github, there are a few more steps in the process. See this Discourse thread for more details on that process.
Not quite what you're asking for but you can of course always git clone the package to a path of your choice and then dev path/to/the/local/clone/of/the/pkg.
You can even do this from within julia:
using Pkg
Pkg.GitTools.clone("<pkg url>", "<local path>")
Pkg.develop(PackageSpec(path="<local path>"))
I am working on a Symfony 2.7 project. I ran composer update --dry-run to check which packages could need an update. Composer notified me about a deprecated package:
Package symfony/icu is abandoned, you should avoid using it. Use
symfony/intl instead.
I simply removed the dependency from the composer.json file and ran composer update --dry-run again. The message did not show up again, symfony/icu was uninstalled and symfony/intl was not installed.
Fine, this means that non of the other requirements depends on symfony/icu or symfony/intl. But can I be sure, that non of my own code requires any of these packages?
I created the project white a while ago and I do not remember why I added symfony/icu. I is possible, that the code that once required this packages has been removed, but I am not sure.
I used grep to search for any import of symfony/icu and found nothing. However that does not guarantee, that the package is not uses somewhere within my code, does it?
Is there any way to check if there are any dependencies within the complete Symfony project that require a specific package?
Check for every package? :(
I think you can do this only with automated testing.
There are no tools (I'm aware of) to detect whether some package is required to complete missing classes. There are also optional dependencies (package works without them, but with them will add some new features), so you will find missing classes but not required to run application.
How to check one package? :)
You heading right direction with grep. Yet rather look for namespace instead of package name. Package name is not always 1:1 to package namespace.
I would look for:
repo on Github: https://github.com/symfony/icu
open some file: https://github.com/symfony/icu/blob/1.2.x/IcuRegionBundle.php
find namespace
namespace Symfony\Component\Icu;
then search for "Symfony\Component\Icu" in code in PhpStorm or grep
I think the cleanest way is to start with composer and tell it dump all packages that caused your package to install:
For example, I'm trying to figure out why monolog/monolog is installed:
$ composer depends monolog/monolog
symfony/monolog-bundle 2.11.1 requires monolog/monolog (~1.18)
So monolog/monolog was installed because of symfony/monolog-bundle.
As you said you might have unintentionally use a package that's a dependency of another package so you didn't add it to your dependencies.
I'd use grep just as you did to search my source code. Just note that it's better to search for an actual class name, not the package name. Searching for package name would give you composer.json files but that's easier to analyze with composer depends than grep:
$ grep --include=\*.php -rnw './vendor' -e 'use Monolog'
./vendor/monolog/monolog/src/Monolog/ErrorHandler.php:16:use Monolog\Handler\AbstractHandler;
./vendor/monolog/monolog/src/Monolog/Formatter/ChromePHPFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/FluentdFormatter.php:45: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s FluentdUnixFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/GelfMessageFormatter.php:14:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/HtmlFormatter.php:13:use Monolog\Logger;
./vendor/monolog/monolog/src/Monolog/Formatter/NormalizerFormatter.php:34: throw new \RuntimeException('PHP\'s json extension is required to use Monolog\'s NormalizerFormatter');
./vendor/monolog/monolog/src/Monolog/Formatter/WildfireFormatter.php:14:use Monolog\Logger;
This command searches all *.php files and dups also line numbers containing Monolog.
Unfortunately, the these two methods just analyze your code post-mortem. Really the best way to avoid dealing with this is to write unit tests. Then clone your fresh repository, install dependencies with composer install and run tests. This should guarantee that your code is run in isolation from any other unwanted dependencies.
I have a local package that I am writing. I wanted to extend some functionality from a few of the core meteor packages. In order to do this, I was creating another local package.
So now local package A is attempting to use local package B. But even after adding the symlink to package A's packages folder, I get an unknown package error when running test-packages.
meteor add local-package-b
Doesn't work because meteor complains: You're not in a Meteor project directory
Is this even possible or do I need to publish to atmosphere first? I wanted to keep the additional package local as it's going to be a handful of helper methods.
I've double checked the name in package B's package.js file and it matches with my api.use in package A's package.js file.
Symlinks shouldn't be necessary here. Local packages are found by checking:
Anything under the directory pointed to by the environment variable PACKAGE_DIRS.
Anything under the packages directory in the current application directory.
Core packages.
As long as your two packages reside in one of those three locations, the should be found. Also see my article on local packaes for more details on (1).
Based on our conversation below, the main issue had to do with the approach to creating a new package. While it's being written, it's necessary that a package be added to (or tested by) an app. Here are the steps I take when working on a shared, local package:
Create a new app.
meteor create --package mypackage
meteor add mypackage
Finish writing and testing the package.
Move mypackage under my PACKAGE_DIRS directory so it will be available to other apps.