how to synchronize dependencies with Altair? about altair HOT 7 CLOSED

Related question: Will altair require a specific version of Altair?

from altair.

I have been wrestling with this question for a while, so I will be very happy for your thoughts - especially as I am somewhat unsure of my reasoning.

I think an essential question is how to we keep the installation-method for the Python package, install_altair(), current with the version of the js libraries in inst/htmlwidgets?

For Altair, there will be three ways to install:

• pure Conda, which should be available in the near future for v2
• PyPi, which is being used also for release-candidates. In the new-docs branch, the install_altair() function currently installs into Conda using pip for altair==2.0.0rc2
• directly from github (which I have not tried yet using reticulate::install_conda()).

By hard-coding our install_altair() function, we could specify which way is to be used, giving us a mechanism to support a specific version. We could have a check_altair() function to see if the installed version matches the required version, but I don't know if we could have it run .onLoad() for fear of rendering moot the delay_load.

As you point out, each of these Altair versions will be tied to specific versions of the JS libraries. Perhaps, as a part of our development process, we should ensure that the JS libraries in inst/htmlwidgets are the same as used by Altair, according to the version installed using install_altair().

This leads to another question about how we manage the development process (I still need to write that contribution guide...).

As a first idea, and I am toying with this now, perhaps we can use three main types of branches:

• master uses a released Conda version (uses release candidate from PyPi only until V2 is officially released)
• devel can use a release candidate from PyPi
• <feature-branch> can use a github version of Altair

I'm sure you recognize this from gitflow; I am trying to see what adaptations can be made so we can incorporate a dev version of the documentation in pkgdown.

What do you think?

from altair.

Hard-coding a version in install_altair seems like a good idea. The branching sounds reasonable, although then a contribution guide will be very necessary 😄

It seems like reticulate there is an option to add a function as an argument to delay_load, where that function executes on loading. There is also an option for what to do on error. So we could do:

check_altair <- function() {
  # Placeholder -- stuff will go here
}

on_altair_load <- function(){
  check_altair()
}

on_altair_error <- function(e){
  message("Error importing Altair")
  message("Please try using install_altair to install")
}

.onLoad <- function(libname, pkgname) {
  alt <<- reticulate::import("altair",  delay_load =
                               list(on_load = on_altair_load,
                                    on_error = on_altair_error))
}

See example from keras

Additional notes:

alt has some properties:

alt$VEGALITE_VERSION
alt$VEGAEMBED_VERSION

These could be checked to make sure they match the versions of altair r package (is there a way to get this from widget yaml?)

from altair.

oooh, I like these ideas... will think on this today!

from altair.

Just to build off of your ideas:

Hard-coding an option in onLoad(),

.onLoad <- function(libname, pkgname) {

  options(altair.python.supported.version = "2.0.0rc2")

  alt <<- reticulate::import(
    "altair",
     delay_load = list(
       on_load = on_altair_load,
       on_error = on_altair_error
     )
  )
}

could check_altair() look something like this?

check_altair <- function() {

  # check that Altair is available
  has_altair <- reticulate::py_module_available("altair")
  assertthat::assert_that(has_altair, msg = "Python package Altair not found")

  # check that version is supported
  version_installed <- alt$`__version__`
  version_supported <- getOption("altair.python.supported.version")
  if (!identical(version_altair, version_supported)) {
    warning("informative warning goes here")
  }
}

could we suggest a call to reticulate::py_config() in on_altair_error()? or even call it?

Restating my comment from the other issue, I think that it will be our responsibility to ensure the versions of the JS libraries we supply in inst/htmlwidgets work with the Altair version we support in "altair.python.supported.version".

It's too bad that alt$VEGALITE_VERSION and alt$VEGAEMBED_VERSION might not be as useful as we hoped...

from altair.

That seems like a reasonable approach! I'm not sure if the has_altair call in check_altair is necessary though-- if that is being used as on_load in import, I think it would only get called if altair was successfully loaded.

Calling or suggesting reticulate::py_config() in on_altair_error() sounds like a good idea!

I agree that making sure the JS libraries work for the supported Altair version is the responsibility of this package and its maintainers.

One thought about the warning/check for altair version-- perhaps there should be an escalation based on how off the version is:

• Patch version difference only leads to message
• Minor version difference leads to warning
• Major version difference leads to error (versions < 2 for example will definitely be very problematic)

from altair.

You're right! The first bit is redundant - I should have seen that... thanks!

I like the escalation idea!

from altair.