You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the examples, the following pattern is observed for specifying the local artifacts folder:
ARTIFACTS_FOLDER=os.getcwd()+"/artifacts"
Note that if the os.getcwd() call is ommited, the example will work locally (within the Python process), but fail to deploy on Docker with an error message which is not very transparent:
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/models/model.pickle'
This leads me to believe that an absolute path is necessary for deployments to work. If that is the case, this should be documented in the Model class and model decorator docstrings as well as in the docs more prominently (maybe a warning box?). To make the user experience even better, we could also consider the following:
convert relative paths to absolute ones (if no intended side-effects)
issue a warning if the path is relative and/or propagate the error with a custom message so the FileNotFoundError is more informative
Finally, perhaps we could think about accepting pathlib.Path objects anywhere we accept strings that represent paths? This would avoid many common mistakes when constructing paths "by hand" and could be more platform-agnostic.
In the examples, the following pattern is observed for specifying the local artifacts folder:
Note that if the
os.getcwd()
call is ommited, the example will work locally (within the Python process), but fail to deploy on Docker with an error message which is not very transparent:This leads me to believe that an absolute path is necessary for deployments to work. If that is the case, this should be documented in the
Model
class andmodel
decorator docstrings as well as in the docs more prominently (maybe a warning box?). To make the user experience even better, we could also consider the following:FileNotFoundError
is more informativeFinally, perhaps we could think about accepting
pathlib.Path
objects anywhere we accept strings that represent paths? This would avoid many common mistakes when constructing paths "by hand" and could be more platform-agnostic.Potentially related issue: #94.
The text was updated successfully, but these errors were encountered: