Updated index links for 0.25.3 #29374
Conversation
|
you can also just build the docs with a local re-tag. I am not sure we should overwrite the tag (though IIRC have before) |
|
Yea tried that but didn’t have any luck with it. Not sure if the docker container plays nice with all of that but could have been a user error on my end. Something else to consider - do we even really need the version hash in the dev docs? Could probably simplify things if we didn’t include that |
its very useful during dev docs to make sure you are looking at updated docs. for the released docs it could be hard coded (but that's another thing to update). |
|
LGTM. @WillAyd is there anything wrong with the docs up at https://pandas.pydata.org/pandas-docs/version/0.23.3/? |
|
Yea if you click on some links in the navbar like the whatsnew one will see the hash appear in title and top left link |
|
this needed for the docs? |
|
Yea the home page of the site was pointing to the 0.25.2 whatsnew when 0.25.3 was released. I think this is a pre-cursor to the release to update this that was missed I did this locally and retagged but I think that still yield the issue in #29398 . Will try to give it another go over the next few days |
Do you remember what went wrong? (I agree that we should not re-tag on pandas upstream for this issue)
It could also show the short version (without the hash), like: 0.26.0.dev instead of 0.26.0.dev0+788.gd5699051a |
Yes this PR wasn't done on 0.25 so when first tagged and the docs were built the front page was still showing 0.25.2. So I made this change locally, deleted the old tag and tagged the new commit containing this PR. However, after building those docs it started showing the commit hash in the version |
|
I understand the part that we forgot to include this when 0.25.2 was tagged, but what I don't understand is why you get a dirty tag locally, after you retagged (why the doc building with the locally retagged version went wrong). The dirty tag normally means that you still did further changes after retagging? |
|
Not sure |
|
Do you still have that environment? What does |
|
I still have the git submodule but I think (?) the docker file creates and then discards what was used. If I try to import pandas locally from the submodule I just get an error that the C extensions are not built |
|
LGTM |
|
I'll try to get the site fixed this weekend. Not ideal but I might just manually remove the hashes from the locations on the website (would take less time than rebuilding docs) |
|
There are 1000+ pages, so "manually" might be a lot of work (unless you mean to manually write a script to do this ;)) |
|
This should be fixed now on the site. What I ended up doing was reverting to the upstream 0.25.3 tag locally and rebuilding from those, then just manually SSHing to make the updates in this PR. Not ideal, but I tried again retagging locally and it still generated the dirty tags. I have a hunch that if there is a remote tag for v0.25.3 that a local tag doesn't get respected, but didn't step through the versioner stuff enough to really prove that out Another thing to consider - the In any case someone better versed in Docker than I may want to consider that change on pandas-release if they know how to make it work. |
|
@WillAyd thanks for the updates! For the pandas-release related things you noted, might be worth opening an issue there |
I think this was supposed to be updated for the release. Might need to retag after repush docs after this
@TomAugspurger