Compatibility with `geetools`

[12rambau]

Hi, I'm the new maintainer of the geetools lib and I'm in a crusade to refactor it as a GEE extention. The big difference between what I'm doing and what you do is that I'm placing all the methods in the "geetools" namespace that is then added to all classes of GEE. The rational is that anybody wanting to create another extention can still do it without risking conflicts and I prevent myself from conflict with earthengine-api updates. This make anything coded in eemont or here incompatible with my lib but we still try to achieve the same goals.

The user management was already hidden by Rodrigo, I simply decided to expose it the same way as you did: ee.Authenticate.geetools.xxx

I don't know what to do with this information but I just wanted to notify you.

I expect 1.x to be released before the end of the year, it will also include some plotting methods. The next step is to use geetools in ipygee to create interactive widgets for Python users (task manager, asset crawling, vanilla map, etc...)

[aazuspan]

Hi @12rambau, I'm very familiar with your contributions on the EE stack exchange, so it's great to finally connect! I just took a look at your work on gee-community/geetools#140, and I can definitely see the similarity in design. It looks like we had a lot of the same API ideas, but you beat me to it by 2 days! If I'd known your work was ongoing, I definitely would have saved myself the time of rebuilding it all from scratch.

The big difference between what I'm doing and what you do is that I'm placing all the methods in the "geetools" namespace that is then added to all classes of GEE. The rational is that anybody wanting to create another extention can still do it without risking conflicts and I prevent myself from conflict with earthengine-api updates.

I like the idea of isolating everything like this. eeauth does check that those attrs don't already exist before setting them, so it will defer to other packages or EE updates, but keeping a separate namespace is much more future-proof (especially since geetools has so many more features than eeauth).

Aside from the namespace, it looks like the biggest difference in terms of implementation is how we chose to store the credentials (one registry file with metadata vs. one credential file per user identified by filename) and the CLI for eeauth. The CLI was actually the main reason I built this, as it allows me to use this with another tool I built to track tasks.

It does seem a little redundant to have two projects with such similar features, so if you have any interest in somehow merging them, I'm open to that idea. Obviously geetools does much more than just authentication, but eeauth has a few features that are important for my use (mainly the CLI and the ability to check which user is initialized/default).

In any case, I'll definitely keep a closer eye on geetools and ipygee in the future. It looks like there's a lot of exciting stuff going on there!

[12rambau]

I'm completely open to merge the authentication mechanism in the same package and call it from geetools. That's what I'm doing for ee_extra to get the same method as eemont with my "namespace" approach.
would you be open to drop the extention part in eeauth and only keep the chore functionalities + CLI and then I could call it from geetools ?

I would be happy to discuss the technical approach then as I discovered in my company some funny use cases with shared credentials.

[aazuspan]

Sounds great!

would you be open to drop the extention part in eeauth and only keep the chore functionalities + CLI and then I could call it from geetools ?

Yeah, I'm open to that. Rather than patching in the as_user methods, I'll just expose the eeauth.initialize and eeauth.authenticate functions. I'll open an issue to track that. Done and released with 0.1.2.

I would be happy to discuss the technical approach then as I discovered in my company some funny use cases with shared credentials.

Great, I'd be interested to hear any issues you've run into that we might need to work around.

[12rambau]

Ok so I still have a lot of things to cover (image collection and batch computing) in the gee_tools refactoring but I'll let this one open until I'll release v1.0.0a0 and we'll have something more tangible to work on.

[12rambau]

The most common use case I got in my company that cannot be covered by your 1 file approach is when the credential folder is shared among different machines in the same server. The main advantage of the 1 file 1 credential is that I keep all the flexibility of asking IT colleagues to move them to a shared folder where I only have reading rights AFTER creation.