Open slaperche-scality opened 5 years ago
Some places expect it to be a string...
When I added support for Path
, I did the easy way just converting it when the task is created.
Since you can easily re-create a Path
. I am not sure it is worth to implement this. I would need to check the code in details to see everywhere a change is required.
I see, it makes sense.
It could be an issue if you have a lot of paths, then the cost of recreating all the Path objects may be noticeable (that being said, that's not an issue I have for now).
If it's not worth implementing, documenting the behavior to make it less surprising can be enough I think.
@slaperche-scality off-topic:
Saw your work on metalk8s, awesome! Also glad you had only 3 (small) requests :grinning: I would really appreciate if you could contribute a success story [1] describing your project, how doit is used, and why doit was chosen.
No problem :slightly_smiling_face: , I'll submit a PR for that :) (probably next week).
The documentation mention that
doit
acceptPath
object insidefile_dep
andtargets
but I noticed that when I got the item back they're no longerPath
object but have been converted to string.e.g:
gives
I would have expected the types to be preserved.
Is it a bug or do you have some internal constraints that force you to convert everything to string?