Closed nleroy917 closed 1 month ago
Hmm.
I'm a little surprised the peppy adjusts the content in the config file, to be honest.
I think instead, peppy should use an internal value where it keeps track of where it actually finds the sample tables, rather than updating the config. @stolarczyk can you comment on this?
@Khoroshevskyi with your experience with all the to_dict stuff, can you comment on this?
Hmm.
I'm a little surprised the peppy adjusts the content in the config file, to be honest.
I think instead, peppy should use an internal value where it keeps track of where it actually finds the sample tables, rather than updating the config. @stolarczyk can you comment on this?
@Khoroshevskyi with your experience with all the to_dict stuff, can you comment on this?
to_dict
function will take all the content of _config
and _sample_df
variables, it won't change anything. But I agree with @nleroy917 , that this variables are changing during peppy processing.
It won't influence on methods that are initializing peppy from dict, but it will initial paths, that can cause errors in the future (e.g. in this Nathans issue).
I think instead, peppy should use an internal value where it keeps track of where it actually finds the sample tables, rather than updating the config. @stolarczyk can you comment on this?
Yeah, this seems like a sensible approach. I'm not sure what was my motivation for implementing it the other way. I would have done what you suggest if this issue had manifested earlier.
Overview
Over at PEPhub, I am implementing a feature to download a PEP as a zipped folder. To do this, I am recapitulating the PEP using the internal state of the
peppy.Project
object returned frompepagent
and the database. However, thepeppy.Project.config
object saves file path configurations as relative to where thepeppy.Project
object was instantiated, rather than the actual value in the file. This becomes problematic when downloading PEPs since the file path in theproject_config.yaml
file and the actual file location are now out of sync. Here is an example:Example
The config file:
At the root of pephub (
/
):Inside the PEP folder (
/examples/demo/basic/project_config.yaml
):Note how the
sample_table
attribute is changing depending on where the PEP was instantiatedI suspect
peppy
uses this state internally to initialize things and it was never intended that the original config file would need to be reproduced. This is less of a bug, I guess, and more of a feature request. I could manually update the internal state ofpeppy.Project
and just strip the relative paths usingos.path.basename
, but it would be nice to have a method that can recreate the PEP assuming all files are next to one another.Supplemental Material :D
Here is the zipping function where I build back up the PEP: