ENH: Added Python version to vetiver_pin_write

[ganesh-k13]

Changes

This adds the python system information to the metadata

Note

Hey folks! I found your repo through PyData NYC and was interested in contributing mainly to the deployment aspect. This is a basic PR for one of the issues to get a hang of the project.

Testing:

There is no UT :) It's inside another folder, my bad
Sample run:

> cat test_v.py
from vetiver import mock, VetiverModel, VetiverAPI, vetiver_pin_write
from pins import board_temp

X, y = mock.get_mock_data()
model = mock.get_mock_model().fit(X, y)

v = VetiverModel(model, model_name='mock_model')

model_board = board_temp(versioned = True, allow_pickle_read = True)
vetiver_pin_write(model_board, v)

loaded_v = VetiverModel.from_pin(board=model_board, name='mock_model')
print(loaded_v.metadata)

Model Cards provide a framework for transparent, responsible reporting. 
 Use the vetiver `.qmd` Quarto template as a place to start, 
 with vetiver.model_card()
Writing pin:
Name: 'mock_model'
Version: 20230113T202728Z-1a387
VetiverMeta(user={}, version='20230113T202728Z-1a387', url=None, required_pkgs=['scikit-learn'], python_version=(3, 10, 6, 'final', 0))
/home/ganesh/os/mlops/vetiver-python/hostt.py:19: DeprecationWarning: argument for checking input data prototype has changed to check_prototype, from check_ptype

Alternatively

We could add it to _model_meta to make it global? Seemed too invasive so wanted a second opinion

resolves: #115

[isabelizimm]

Welcome Ganesh! Thank you so much for this contribution, and it was great to meet you at PyData NYC. :)

I think _model_meta is the correct spot for this, since the user section on a VetiverModel should be user-given metadata. I'm currently working on a metadata refactor in #126 that should make the addition of new fields a lot easier (and clean out the user field). Once that PR is in, let's look at adding python_version to _model_meta!

[ganesh-k13]

Ah that makes sense, thanks for the info! Will keep an eye out for that PR and rebase when done. Will keep looking around other stuff in the project meanwhile 👍

[isabelizimm]

Ah that makes sense, thanks for the info! Will keep an eye out for that PR and rebase when done. Will keep looking around other stuff in the project meanwhile 👍

Hi Ganesh-- the other PR (#126) has been merged! It should be easier to add the Python version to the metadata dataclass now :)

[ganesh-k13]

Thanks! Sorry was not active, had a few ideas but got caught up. I'll try to finish it this week.

[isabelizimm]

One comment on sys.version vs. sys.version_info, but this looks so great 💯 I appreciate you getting your hands on the new metadata structure!

[isabelizimm]

Suggested change

	python_version = metadata.get("python_version", sys.version)
	python_version = metadata.get("python_version", sys.version_info)

Later on, I think we want to be able to quickly compare the version of Python that the model was originally written with the version of Python that the user has locally (if model is read in from some other location). Using version_info for a tuple rather than a string will probably be more straightforward for this comparison.

[ganesh-k13]

Thanks! That makes sense. I had pickling issues with tuples(yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:python/tuple'), so I'm kinda handling it in a not-so-favorable way here: pin_read_write.py. I guess there are no issues as the end user will still deal with tuples, but please do let me know if a cleaner approach pops up.

[isabelizimm]

Ah, I see that! I don't believe there is a cleaner approach, but will keep that in mind 👀

[isabelizimm]

Looks great! Thank you so much @ganesh-k13 🙌