Open isabelizimm opened 1 year ago
This is related to rstudio/vetiver-r#154
Thanks for this! It feels like the end goal here can be tricky to parse from the language specific details here. For example, when comparing the R and python programs, I noticed for docker deployment, they differ how they pin package versions for users.
Can we write out somewhere the high-level rules, and cases they apply to (without any mention of technical solutions)? It'd help to hear the end result users should expect to see in terms of versions installed.
Here's a rough example (which may be wrong):
<stats_model_package>
.<some_package>
, then rebuilding the Dockerfile should use the same version for that package.<some_package>==0.0.1
, but <some_package>==0.0.2
is compatible, it's okay if a resolver pins to 0.0.2
.Ah, that's a good way to establish what needs to happen! I think you have it mostly right, but this will mainly happen at writing/reading pins:
Purpose of this to check that the versions of the model package and vetiver are the same at pin read as when it was originally written to pin.
vetiver_pin_write
, the version of vetiver
package the user has installed when they write the pin will be saved in metadata at requirements
pins
, fastapi
, and <stats_model_package>
packagesVetiverModel.from_pin
, a message is shown if any of the above packages do not match the version the user has installed at pin write.<some_package>==0.0.1
, but <some_package>==0.0.2
is compatible, it's okay if a resolver pins to 0.0.2
.This should be mostly invisible to users. If people are interested in looking at this file, they are able to do so via board.pin_meta
.
This conversation is starting to get lost in #126, so bringing it over here :)
From @juliasilge
The general idea would be that instead of
required_pkgs
, there would be an argument calledrequirements
orrequirements_txt
. The default would be whatrequired_pkgs
does currently: give the names of the minimal required packages to make predictions at a model's endpoint. There could be another argument that would make this minimal requirements be more robust. The top level requirements would include the version (ie, vetiver==0.1.8 and scikit-learn==1.2.0), and pip-tools would be used to find the second-level compatible version. (There is the issue with just doingpip freeze
is that it will include everything in the environment, and maybe more annoyingly, is not a guarantee that the environment can be recreated.)So,
could output something like:
or something like below, where it is generated from a pinned
vetiver==0.1.8
andscikit-learn==1.2.0
:CC: @machow @juliasilge