Pin sphinx-autoapi==2.0.0 version

[pankajastro]

Description

What is the current behavior?

build-docs is broken on sphinx-autoapi-2.0.1

Warning, treated as error:
/Users/pankaj/Documents/astro_code/astro-sdk/python-sdk/docs/autoapi/astro/databases/base/index.rst:80:more than one target found for cross-reference 'FileType': astro.constants.FileType, astro.files.types.base.FileType
make: *** [html] Error 2

What is the new behavior?

pin sphinx-autoapi to 2.0.0

Does this introduce a breaking change?

Checklist

• Created tests which fail without the change (if possible)
• Extended the README / documentation, if necessary

[codecov]

Codecov Report

Base: 97.73% // Head: 93.02% // Decreases project coverage by -4.71% ⚠️

Coverage data is based on head (4c4daba) compared to base (6864dec).
Patch has no changes to coverable lines.

❗ Current head 4c4daba differs from pull request most recent head 42459bb. Consider uploading reports for the commit 42459bb to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1609      +/-   ##
==========================================
- Coverage   97.73%   93.02%   -4.71%     
==========================================
  Files          22       90      +68     
  Lines         794     4472    +3678     
  Branches        0      444     +444     
==========================================
+ Hits          776     4160    +3384     
- Misses         18      223     +205     
- Partials        0       89      +89     

Impacted Files	Coverage Δ
python-sdk/src/astro/sql/operators/cleanup.py	96.15% <0.00%> (ø)
python-sdk/src/astro/files/base.py	100.00% <0.00%> (ø)
python-sdk/src/astro/sql/operators/export_file.py	100.00% <0.00%> (ø)
python-sdk/src/astro/utils/load.py	92.30% <0.00%> (ø)
python-sdk/src/astro/__init__.py	100.00% <0.00%> (ø)
python-sdk/src/astro/sql/operators/load_file.py	96.93% <0.00%> (ø)
python-sdk/src/astro/files/types/csv.py	100.00% <0.00%> (ø)
python-sdk/src/astro/databases/sqlite.py	95.31% <0.00%> (ø)
python-sdk/src/astro/settings.py	100.00% <0.00%> (ø)
python-sdk/src/astro/table.py	98.96% <0.00%> (ø)
... and 58 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[feluelle]

@pankajastro to me this does not sound like an error. It is a warning which we treat as an error - and we should resolve this.

[utkarsharma2]

@feluelle It makes sense to me when there are multiple references to FileType(in constant and file module), but it's raising this issue even when there is only one reference. I think's an issue with Sphinx right?

An alternative would be to update the codebase to use FileType as FileTypeConstant which I think is unnecessary when there is only one FileType in the namespace. WDYT?

[feluelle]

Okay, can't we be more specific and help sphinx to find the right FileType somehow?

[pankajastro]

@pankajastro to me this does not sound like an error. It is a warning which we treat as an error - and we should resolve this.

Looks like some issue on sphinx-autoapi side though I have not investigated it thoroughly since we have simple case two class have same name and we are importing one of them.

[feluelle]

here and here we have FileType but in the latter one, we "import as" 🤔 Maybe indeed a bug?
Do we need to import both btw? I think we can remove one, no?

yes, we can remove one but after that it fail https://github.com/astronomer/astro-sdk/blob/main/python-sdk/src/astro/databases/base.py#L69 where we have one import

[utkarsharma2]

Okay, can't we be more specific and help sphinx to find the right FileType somehow?

Even then we are having issues when there is only one import with FileType. I think it's an issue on autoapi side, we can fix it at our end but that will lead to multiple code changes on our end. I think for now maybe we can pin it to the older version and wait for a fix. @feluelle WDYT?

[feluelle]

Alright. Let's wait for a fix and revisit next time we come across the comment.