Call current user API v1/user during sdk client initialization.

[dbkegley]

• add reference to client obj for all Resources
• make client.resource initialization lazy

Note: I didn't fix the tests in endpoints_test.py because it looks like that code is replaced by the new Resource types.

Should we remove endpoints.py?

[nealrichardson]

Do we actually need (or want) to cache ._users? If I do a new query, I want to start fresh. And instantiating Users() should be basically free.

Suggested change

	if self._users is None:
	self._users = Users(client=self)
	return self._users
	return Users(client=self)

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
493	440	89%	80%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
src/posit/connect/client.py	100%	🟢
src/posit/connect/client_test.py	100%	🟢
src/posit/connect/users.py	55%	🟢
src/posit/connect/users_test.py	100%	🟢
TOTAL	89%	🟢

updated for commit: 3246cc3 by action🐍

[tdstein]

Do we want to instantiate a new instance every time? The Users class is designed to fetch from the server once, and then use cached results for subsequent iterations.

There are pros and cons to fetching from the server every time.

We currently don't have any methods that mutate the server, but when we do, my thought is to invalidate the cache on methods that mutate (post, delete, put). This would trigger a fresh fetch on the next iteration.

[tdstein]

Also, passing self to Users instead of the session and config seems odd. This makes client.users.client.users.client.users valid

If the goal is to reduce the boilerplate of passing two variables down to one, I would prefer creating a DTO object that wraps session and config. But, I still think that is overkill at this stage.

[nealrichardson]

The Users class is designed to fetch from the server once, and then use cached results for subsequent iterations.

I think instantiating from Client every time gives you the behavior you want. If you (the SDK user) want to use the cached results, do something like all_users = client.users.find() and work with all_users as much as you want. But some actions you'll want to do will modify the collection on the server, and you'll want a way to refresh. So then you go to client.users again.

[nealrichardson]

Also, passing self to Users instead of the session and config seems odd. This makes client.users.client.users.client.users valid

True, but IME it's useful to be able to get back to the original connection object from wherever you are in the API.

If the goal is to reduce the boilerplate of passing two variables down to one, I would prefer creating a DTO object that wraps session and config. But, I still think that is overkill at this stage.

Isn't Client already the object that wraps session and config?

[dbkegley]

I don't really have any strong opinion about how this happens. My only requirement at this stage is that there is some way to get information about the currently authenticated user from the v1/user endpoint. I need this information to be available in the OAuthIntegration Resource.

I'm fine with changing to approach to use DI instead if that's preferred. For example:

def OAuthIntegration(Resource):
  def __init__(self, current_user: CurrentUser[Resource]):
    ...
    
  def get_credentials():
    guid = self.current_user.get().get('guid')

[tdstein]

True, but IME it's useful to be able to get back to the original connection object from wherever you are in the API.

session holds the connection here.

Isn't Client already the object that wraps session and config?

Yes, but circular references should generally be avoided.

[nealrichardson]

I pulled the changes into #51, the conflicts with main were a bit much.