Release r5r v2.4.0

[rafapereirabr]

Preparing to release v2.4.0.

Conveyal is planning to release an update of R5 in the next few weeks. We'll wait for them.

• git pull
• Check current CRAN check results
• Advance deprecations, if needed
• Polish NEWS
• urlchecker::url_check()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• revdepcheck::revdep_check(num_workers = 4)
• Update cran-comments.md
• git push
• Draft blog post

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• Finish & publish blog post
• Add link to blog post in pkgdown news menu
• usethis::use_github_release()
• usethis::use_dev_version(push = TRUE)
• Share on social media

[alexmgns]

@rafapereirabr if the new version of R5 isn't plug and play please @ me. I'd be happy to take a look at it.

[rafapereirabr]

The new version of R5 v7.5 is out! Thanks Conveyal!

@alexmgns , I've tried to run a CMD Check for the dev version of r5r but I got the following error related to Java. Could you please have a look at this ?

Building network:

devtools::load_all(".")

# build transport network
data_path <- system.file("extdata/poa", package = "r5r")
r5r_network <- build_network(data_path = data_path)

Running cmd check:

Sys.setenv(NOT_CRAN = "true")
devtools::check(pkg = ".",  cran = FALSE, env_vars = c(NOT_CRAN = "true"))

Error message:

   --- re-building 'accessibility.Rmd' using rmarkdown
   
   Quitting from accessibility.Rmd:53-59 [unnamed-chunk-3]
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   <error/rlang_error>
   Error in `build_network()`:
   ! java.lang.RuntimeException: File format version is nv3, this R5 requires nv4
   ---
   Backtrace:
       ▆
    1. └─r5r::build_network(data_path)
    2.   └─rJava::.jnew("org.ipea.r5r.R5RCore", data_path, verbose, elevation)
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[mattwigway]

The above-referenced PR should be merged before this release or the isochrone function will be broken out of the box due to upstream changes.

[mattwigway]

Also, regarding the above-referenced error, the proximate issue is that network.dat built with R5 7.4 is not compatible with R5 7.5, due to changed transfer handling (R5 now stores GTFS transfers, though unfortunately the structure only allows for stop-to-stop transfer specifications so not fixing #471). If you just delete the cached network.dat file, that solves the immediate issue, but brings up another issue on the Java side because loading a network now requires specifying a GTFS TransferConfig, and we'll need to decide how to handle that. The most conservative approach is to specify OSM_ONLY, which will reproduce the behavior of previous versions of r5r, only finding transfers through the street network. Alternately, we could specify STOP_TO_PATTERN or STOP_PAIR, which will use OSM only for transfers from a stop to stops on other trip patterns that do not have an explicit GTFS transfer, or for all stop pairs that do not have an explicit GTFS transfer (these should be pretty similar). For completeness there is also GTFS_ONLY which does not use OSM to find transfers at all and only allows the transfers specified in GTFS, but I don't think I've ever seen a feed where this would be appropriate.

[mattwigway]

Unfortunately I think releasing r5r with r5 7.5 is blocked upstream, see discussion on #544

[rafapereirabr]

Hi @mattwigway and @alexmgns . I was hoping it would not take too long for the Conveyal team to fix hat issue upstream in R5 but it seems it is taking longer than I expected. What do you think? Shall we submit a new version of r5r to CRAN as it is then ?

[mattwigway]

I could see submitting to CRAN as is. I also thought about workarounds a little and I think there are a few possibilities:

1. Modify Build JAR on R build #545 to depend on r5 through gradle rather than downloading the release JAR. This will definitely work and is more future proof, as it seems like Conveyal may stop publishing the release JAR at some point. I think the biggest sticking point is that r5 is published to the Github Packages maven repo, which is publicly accessible but requires a Github access token (it can be anyone's access token but there has to be a token, I guess so they can cut off people who abuse it). I'm not sure how we'd get the token into the CRAN build though without exposing it to the world. I know CRAN wants builds to be reproducible so probably doesn't have a mechanism for build secrets to get injected—though in this case the secret doesn't really make the build non-reproducible, if you wanted to build it yourself you just need to get your own API key.
2. Much more hacky, but just adding gt-epsg-hsql 25.2 to the classpath manually might solve the problem. I don't like it though because then you'll have multiple copies of geotools which I could see causing problems later on.

[alexmgns]

Just to confirm, my last understanding of this issue based on what I read in #544

you can build a network as long as you don't use transit

Is it still the case that you can't include any transit in your network? If it is, I don't think it makes sense to publish to CRAN.

I agree with @mattwigway that since conveyal is planning to move away from publishing this jar (conveyal/r5@1bf792f) it makes a lot of sense to add it to gradle instead, we can then use a shadowjar just like R5. I've experimented with it already for #369 and it works fine with minimal changes.

[alexmgns]

What if instead of including R5 we include a maven resolver like https://mvnrepository.com/artifact/org.apache.maven.resolver/maven-resolver-api and then use that to download all the dependencies without needing users to also install gradle/maven.

Nevermind this still has the github token issue.