MNT: Run PTH flake test in prep for supporting pathlib (io.votable)#17002
MNT: Run PTH flake test in prep for supporting pathlib (io.votable)#17002neutrinoceros wants to merge 1 commit intoastropy:mainfrom
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
810cf4d to
37eafa4
Compare
|
|
||
| def get_attribute_path(self): | ||
| return os.path.join(self.get_dirpath(), "values.dat") | ||
| def get_attribute_path(self) -> Path: |
There was a problem hiding this comment.
I'd rather not. This is API change and I use this downstream in astroquery.
There was a problem hiding this comment.
In general, we should probably leave validator alone.
There was a problem hiding this comment.
I agree this should be done in a separate PR as an API change. But I think this is a good thing to do long term. We should probably also consider deprecating getter and setter methods in favor of @property.
There was a problem hiding this comment.
Oh I don't know why I thought this would be private API. I'll revert the breaking change for now, but it should be simple enough to futureproof astroquery against such a change: wrapping all calls to this methods with os.fspath() would do the trick.
There was a problem hiding this comment.
I revamped this as a set of Path returning private properties + str returning public accessors. No API breakage yet, but a clear path forward: properties can be made public and accessors deprecated. What do you guys think ?
nstarman
left a comment
There was a problem hiding this comment.
LGTM.
I don't like how many files are untested, which is no fault of this PR, but does mean we should get explicit approval from the sub-package maintainer.
|
|
||
| def get_attribute_path(self): | ||
| return os.path.join(self.get_dirpath(), "values.dat") | ||
| def get_attribute_path(self) -> Path: |
There was a problem hiding this comment.
I agree this should be done in a separate PR as an API change. But I think this is a good thing to do long term. We should probably also consider deprecating getter and setter methods in favor of @property.
37eafa4 to
76355c0
Compare
f621046 to
035da28
Compare
|
Can you please rebase? I just merged the |
035da28 to
7168994
Compare
|
done |
There was a problem hiding this comment.
I am still not sure about the validator changes. Is there a reason why we cannot just exclude it from this ruff check? If you must, I think it should be a separate PR because not everyone that uses io.votable use validator, but I do use the validator and I need extra time to vet it downstream.
bsipocz
left a comment
There was a problem hiding this comment.
With the potential downstream implications, I would very strongly prefer this not being merged into 7.0. It's just simply too close to feature freeze and we don't need a fire artificially added on the pyvo/astroquery tables messing up our already set timelines and roadmaps.
|
@bsipocz , but you would still be open to this getting merged for v7.1? I can move the milestone if that is the case. |
Having a ~6month prep period for API changes (dare I say that are added for no good reasons) is more acceptable; but again this makes me wonder if indeed there isn't enough bugs reported in the 1300+ issues so poking around with API changes in code that is being around for a long time and being used downstream but cause no reported problems with is what should take priority just to tick off ruff boxes again? Especially when we talk about paid priorities that don't cause havoc for other maintainers? |
|
I think this PR is being taken a bit out of context. @neutrinoceros has done a good job making sure that this PR does not break any API (e.g. #17002 (comment)). This PR expands the input options to many functions that deal with paths, allowing them to take the recommended |
|
For what it's worth I just ran |
|
Let's punt this to v7.1 then. That way, the validator stuff can stay because I would have time (theoretically) to check it later. I will turn this back into draft for now. Thank you all for your patience and understanding! |
|
Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then. In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary. If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. If you believe I commented on this pull request incorrectly, please report this here. |
|
I'm going to close this pull request as per my previous message. If you think what is being added/fixed here is still important, please remember to open an issue to keep track of it. Thanks! If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here. |
Description
Ref #16924
This is in the continuation of #16060