I think geetools would vastly benefits from adding a asset management class. Many operations are impossible from both the code editor interface AND the cloud API:
change folder name (blocked if the folder is not empty)
delete a folder and all its content (blocked as well if the content is not empty)
check if an asset exist
manage assets the same way as we manage Path in the pathlib lib would be a must (to me)
I don't know if the class should be added to ee like (1) ee.Asset or remain in (2) geetools.Asset. Advantage of option 1 is to keep the door open to extend the javascript lib as well if GEE make a move in this direction (and then the all package could be mirrored there which would be fantastic). 2 is making sure with stay in a more classic development framework and avoid adding complexity to an already overpopulated ee API.
I think geetools would vastly benefits from adding a asset management class. Many operations are impossible from both the code editor interface AND the cloud API:
pathliblib would be a must (to me)I don't know if the class should be added to
eelike (1)ee.Assetor remain in (2)geetools.Asset. Advantage of option 1 is to keep the door open to extend the javascript lib as well if GEE make a move in this direction (and then the all package could be mirrored there which would be fantastic). 2 is making sure with stay in a more classic development framework and avoid adding complexity to an already overpopulatedeeAPI.Happy to read feedbacks !