Conversation
…ents Co-authored-by: amnguye <48961492+amnguye@users.noreply.github.com>
…oint to Azurite connection string Co-authored-by: amnguye <48961492+amnguye@users.noreply.github.com>
Co-authored-by: amnguye <48961492+amnguye@users.noreply.github.com>
…; revert cosmos-sdk-client.yml Co-authored-by: amnguye <48961492+amnguye@users.noreply.github.com>
|
@jalauzon-msft @vincenttran-msft @weirongw23-msft Let me know if there's anything more we should add (you can always update this file later) or anything that needs to be removed from this file. |
There was a problem hiding this comment.
Pull request overview
This PR adds a new sdk/storage/AGENTS.md file that provides Storage-specific guidance for AI agents (Copilot, MCP servers, LLM assistants) working in the sdk/storage/ directory. It complements the existing root-level AGENTS.md by documenting the Storage package inventory, agent rules (don't edit generated code, preserve cross-service API consistency, prefer existing patterns, avoid magic strings), service-specific behavioral semantics, and build/test commands.
Changes:
- Adds a package inventory table and four agent rules scoped to the Storage packages.
- Documents per-service behavioral semantics (Blob, Queue, Files, Data Lake).
- Provides build, test (playback/live/Azurite), and lint/static-analysis command snippets.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…e-datalake, and azure-storage-file-share Co-authored-by: amnguye <48961492+amnguye@users.noreply.github.com>
| - Shared authentication helpers in `_shared/` subdirectories. | ||
| - `StorageConfiguration` and pipeline-building utilities reused across packages. | ||
| - `_serialize.py` / `_deserialize.py` modules for request/response transformation. | ||
| - `StorageRetryPolicy` and connection-string parsing in `azure-storage-blob/_shared/`. |
There was a problem hiding this comment.
I like this rule in principle, but the examples are not the best. The first and third ones are decent but the second and fourth aren't really things we change often and do not have many patterns. I would maybe look for other examples of where a lot of our helpers live (e.g. various _helper files and _handlers files for general stuff and upload and download for upload and download stuff).
| - HTTP header names — use constants from `azure.storage.blob._shared.constants` or equivalent. | ||
| - Service version strings — reference the `X_MS_VERSION` constant (from `azure.storage.blob._shared.constants`) rather than inline strings. | ||
| - SAS permission characters — use the typed permission classes (e.g., `BlobSasPermissions`, `QueueSasPermissions`) instead of raw character strings. | ||
| - Error codes — compare against named constants, not literal strings. |
There was a problem hiding this comment.
Again I like this in principle, but we don't really have shared constants files that we use a lot. _shared.constants is reserved for very specific things otherwise we usually just declare constants at the top of relevant files (and sometimes import them into other files)
|
|
||
| Handwritten (patch) code lives alongside `_generated/` in the package root and in `_patch.py` files. Edits to patch files are acceptable. | ||
|
|
||
| ### Rule 2: Preserve API Consistency Across Blobs, Queues, Files, and Data Lake |
There was a problem hiding this comment.
We could add to this to keep the _shared folders in each package in sync always.
| - Service version strings — reference the `X_MS_VERSION` constant (from `azure.storage.blob._shared.constants`) rather than inline strings. | ||
| - SAS permission characters — use the typed permission classes (e.g., `BlobSasPermissions`, `QueueSasPermissions`) instead of raw character strings. | ||
| - Error codes — compare against named constants, not literal strings. | ||
|
|
There was a problem hiding this comment.
I think we should have another rule around typing. Could have copilot write this but in general (psuedo code):
### Rule 5: Follow typing conventions
- All public types must have a Python 3 style type hint. Private types should also include a type hint when possible.
- Follow existing patterns with regard to types. Especially in the use of `Literal` over any dedicated enum types.
- If adding an import, specifically for typing, that is not used in runtime code, add it to the `TYPE_CHECKING` conditional block.There was a problem hiding this comment.
kwargs should be Optional
| - **Hierarchical namespace**: Rename and move operations on directories are atomic when the storage account has hierarchical namespace (HNS) enabled. On non-HNS accounts, the Data Lake client falls back to Blob operations and these operations are not atomic. | ||
| - **Access Control Lists (ACLs)**: POSIX-style ACLs are only enforced on HNS-enabled accounts. `set_access_control` calls on non-HNS accounts will succeed but have no effect on authorization. | ||
|
|
||
| ## Build and Test |
There was a problem hiding this comment.
Overall, I think it will be quite difficult for an agent to run the Python tests, especially in Live mode. Running tests is typically very manual and you would not really want to run them all at once as that would take hours. Not really sure how we want to approach that.
|
|
||
| ```bash | ||
| cd sdk/storage/<package-name> | ||
| pip install -e ".[dev]" |
There was a problem hiding this comment.
This install command won't actually work. You would want this:
cd sdk/storage/<package-name>
pip install -r dev_requirements.txt
pip install -e .You would also typically want to do this inside a virtualenv but I'm not really sure how that works with agents and if it would be needed or not.
| ```bash | ||
| cd sdk/storage/<package-name> | ||
| azpysdk pylint . | ||
| azpysdk mypy . |
There was a problem hiding this comment.
We should also add azpysdk black . (our formatter)
|
|
||
| ```bash | ||
| cd sdk/storage/<package-name> | ||
| pytest tests/ -v --live |
There was a problem hiding this comment.
I don't think --live is a thing? There is an environment variable for it AZURE_TEST_RUN_LIVE Ture or False
|
|
||
| ### Run tests against a live service or local emulator | ||
|
|
||
| Set the appropriate environment variables for the target package (e.g., `AZURE_STORAGE_ACCOUNT_NAME`, `AZURE_STORAGE_ACCOUNT_KEY` or `AZURE_STORAGE_CONNECTION_STRING`), then: |
There was a problem hiding this comment.
It's just STORAGE_ACCOUNT_NAME and STORAGE_ACCOUNT_KEY for Python and we don't support connection strings.
Overall though auth will be quite tricky as there are actaully many different account types with many env vars. See here. Various tests use various accounts. Also, some tests use OAuth in which case they don't use an account key but would need DefaultAzureCredential to work so the agent would have to run az login or something.
Add The
sdk/storage/AGENTS.md