Updated index links for 0.25.3
State: closed

I think this was supposed to be updated for the release. Might need to retag after repush docs after this

@TomAugspurger 

Labels:
name: Docs

Comments:
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
> 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
> > 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.

Do you remember what went wrong? (I agree that we should not re-tag on pandas upstream for this issue)

> 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).

It could also show the short version (without the hash), like: 0.26.0.dev instead of 0.26.0.dev0+788.gd5699051a
> Do you remember what went wrong? (I agree that we should not re-tag on pandas upstream for this issue)

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 `pd.__version__` give you in a console?
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 `make doc` build does away with the container that creates the docs on completion, so no way to really debug issues. I tried adding `--rm=false` in the Makefile for that step but it still didn't keep the container around, though may also be due to the PDF generation failure. 

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