You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Accessing the StacIO instance associated with a Catalog is currently only possible using the _stac_io attribute. Using the underscore convention indicates that this property is for internal library use only and not something that should be manipulated by downstream libraries. However, there are a few places in pystac-client where it is necessary to manipulate this attribute, and in stac-utils/pystac-client#126(comment) this came up as possible being a bad pattern/code smell.
In #590 we considered adding a "public" Catalog.stac_io attribute that could be used by downstream libraries to manipulate the _stac_io attribute of a Catalog, but ultimately decided it was not necessary as part of that PR. I would like to revisit that decision given that we now have some additional use-cases for manipulating the attribute outside of PySTAC.
The purpose of this issue is to discuss whether we should add a "public" Catalog.stac_io property that allows users to manipulate with the underlying Catalog._stac_io attribute. Given that downstream libraries are using the "private" Catalog._stac_io attribute we should probably retain that attribute until the next major release.
The text was updated successfully, but these errors were encountered:
Accessing the
StacIO
instance associated with aCatalog
is currently only possible using the_stac_io
attribute. Using the underscore convention indicates that this property is for internal library use only and not something that should be manipulated by downstream libraries. However, there are a few places inpystac-client
where it is necessary to manipulate this attribute, and in stac-utils/pystac-client#126(comment) this came up as possible being a bad pattern/code smell.In #590 we considered adding a "public"
Catalog.stac_io
attribute that could be used by downstream libraries to manipulate the_stac_io
attribute of aCatalog
, but ultimately decided it was not necessary as part of that PR. I would like to revisit that decision given that we now have some additional use-cases for manipulating the attribute outside of PySTAC.The purpose of this issue is to discuss whether we should add a "public"
Catalog.stac_io
property that allows users to manipulate with the underlyingCatalog._stac_io
attribute. Given that downstream libraries are using the "private"Catalog._stac_io
attribute we should probably retain that attribute until the next major release.The text was updated successfully, but these errors were encountered: