fix: add fetch to packages protocol

[tdstein]

No description provided.

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
1948	1790	92%	0%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
src/posit/connect/client.py	99%	🟢
src/posit/connect/content.py	96%	🟢
src/posit/connect/packages.py	0%	🟢
TOTAL	65%	🟢

updated for commit: 9274727 by action🐍

[tdstein]

@schloerke - I want to expose Package, Packages, ContentPackage, and ContentPackages so that they may be imported via from posit.connect import Package, Packages, ContentPackage, ContentPackages. Do you know if it's better practice to make them public here or to keep them private and then rename them as public in src/posit/connect/__init__.py?

[schloerke]

I'm up for removing the leading _ from all the names. They are public or things package authors might use and so they should be available in the posit/connect/__init__.py file.

I would argue for renaming almost every file to start with a _ though. Ex: jobs.py to _jobs.py. Variables like JobTag are currently considered public and stable. (I would keep the ./external folder and files as they are as their use case is different than most of the code.)

With the renaming of the jobs file (for example), it would be good to expose Jobs and Job through the init file just like Package and Packages.

---

If you still like the cadence of from posit.connect.jobs import Job, Jobs (which I also enjoy), we could turn the file structure into something like

./jobs
    | - __init__.py # Exposes `Job` and `Jobs`
    | - _jobs.py # The current content of `./jobs.py`

This would hide all variables and only expose what you want to expose through posit.connect.jobs. We could even re-export those variables in the top level posit.connect where appropriate.

---

Repeating with Packages...

./packages
    | - __init__.py # Exposes `Packages` and `Package`
    | - _packages.py # The current content of `./packages.py`

Links to a py-shiny implementation of this:
https://github.com/posit-dev/py-shiny/blob/7ae7725e2dc082fb02b4bcfac44c60669dc8d501/shiny/session/__init__.py where Session is from https://github.com/posit-dev/py-shiny/blob/7ae7725e2dc082fb02b4bcfac44c60669dc8d501/shiny/session/_session.py and also re-exported at the top level at https://github.com/posit-dev/py-shiny/blob/7ae7725e2dc082fb02b4bcfac44c60669dc8d501/shiny/__init__.py

It allows for both from shiny import Session and from shiny.session import Session (and internally we can also call ./session/_session import Session)

[schloerke]

I could also see a benefit of a ./protocols.py or ./types.py file that re-exports all of the Protocol classes. This might be useful to help drive home that they are not implementation classes, but just types.