Website performance issues

A user reported some website loading issues at scipy/scipy#23756. I've also noticed these, especially when I traverse into the SciPy stable release docs via i.e., a Google search for some specific object, like ConvexHull.

In my hands, the page loads do seem to typically succeed in the end, but the experience is far slower than equivalent navigation in the https://scipy.github.io/devdocs/. These are using two different hosting solutions, IIRC.

As far as action items, we could perhaps touch base with the folks hosting the stable release docs (Enthought folks still? I have some old email chains b/w Ralf and an admin there IIRC). I'll make a calendar reminder to look through those emails when I have access to Gmail (not at work, unfortunately).

FWIW, I set up a monitoring system using UptimeRobot to get data on when the downtime / slowness was. It works by making an HTTP request to https://docs.scipy.org/doc/scipy/building/index.html?uptime-robot-monitoring-contact-nickodell-for-issues=None and measuring how long it takes and whether it succeeds. Since I started tracking this data on Sep 29th, on average, it shows about 99% uptime and a mean of 2700 ms latency.

I haven't been able to see any patterns in this graph so far.

@dpinte

@dpinte You were able to help us last time from the Enthought side--are you still the correct contact for docs.scipy.org hosting? It seems unusually slow lately per several user reports and we just wanted to check in on that.

@tylerjereddy

@tylerjereddy yes, I am. If I'm not responsive, please ping me by email. I'm flooded with github notifications ... I'm looking into the deployement and check what's going on.

Nothing special reported on the server. It's not a very beefy machine but system stats look good (cpu, memory and storage) Some maintenance will be required at some point though (OS upgrade).

Can you maybe front by cloudflare /fastly and cache ? Or similar ?

+1 for the CDN. I am still puzzled on to why we do not have control on this website and the domain. I asked several years ago and it was not clear and people did not want me to help out so I let it roll sadly.

@Carreau

@Carreau that would definitely be a good idea. I can't promise anything in terms of my availabilities to do it.

@tupui the domain is managed by NumFocus and switched to CloudFare in 2023. And the website has never been transferred with the rest of the ressources. Very happy to support a migration if this is requested. Happy to transfer anything to anywhere and/or provide access to specific ressources.

Very happy to support a migration if this is requested. Happy to transfer anything to anywhere and/or provide access to specific ressources.

I could look into a migration. I would need some information:

What is the CPU / RAM / storage of the current set up? This would be useful for figuring out what the cost of the new service would be. (It's easier to ask for money if I know how much it will be. :) )
Can you provide an approximate number of page hits per 24 hours? This would be useful for capacity planning. Right now it's unclear to me if SciPy has out-grown its current server, or if something is misconfigured.
Could you provide SSH access to allow me to rsync the files that are currently present on the server?

In a plane right now. I'll get back to you asap.

…

On Fri, 17 Oct 2025, 18:37 Nick ODell, ***@***.***> wrote: *nickodell* left a comment (scipy/docs.scipy.org#102) <#102 (comment)> Very happy to support a migration if this is requested. Happy to transfer anything to anywhere and/or provide access to specific ressources. I could look into a migration. I would need some information: 1. What is the CPU / RAM of the current set up? This would be useful for figuring out what the cost of the new service would be. (It's easier to ask for money if I know how much it will be. :) ) 2. Can you provide an approximate number of page hits per 24 hours? This would be useful for capacity planning. Right now it's unclear to me if SciPy has out-grown its current server, or if something is misconfigured. 3. Could you provide SSH access to allow me to rsync the files that are currently present on the server? — Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEDL6FAPZ6FJVL2VKWTXF33YFVTTAVCNFSM6AAAAACI36QVTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMJXGQZTEMJZHA> . You are receiving this because you were mentioned.Message ID: <scipy/docs. ***@***.***>

It is possible that some of the load is on fetching sphinxobj.inv (other projects building docs) which may not appear in page views depending on the method.

@dpinte

I don't think we should do a migration to a new server if we don't understand the problem. The current setup has its issues with deployment, but it works the way it works for a reason.

We had numpy docs on there as well until 2020. We migrated those to static deployment with GitHub Pages, using the https://github.com/numpy/doc repo. That is the alternative here I'd say. The issue with that is that the repo size grows with every minor release. Repo size can be up to 1 GB, for NumPy it's now 400 MB or so - see numpy/numpy#24736 for the latest discussion. The math is fairly simple (I can't find the previous issue about this so quickly, if anyone remembers please post a link). scipy docs are larger than numpy docs, so we can grow it for O(5 years) until we have to reshuffle the repo. Maybe that is the right option now, not sure.

This is the space we're using on the server now (6.7 GB):

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            991M     0  991M   0% /dev
tmpfs           200M   21M  180M  11% /run
/dev/xvda1       12G  6.7G  4.5G  61% /
tmpfs          1000M     0 1000M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs          1000M     0 1000M   0% /sys/fs/cgroup
tmpfs          1000M     0 1000M   0% /run/shm
/dev/xvdg1      296G   14G  267G   5% /srv
tmpfs           200M     0  200M   0% /run/user/1004

We have a habit of uploading new docs for every bug fix release though, and that seems unnecessary - numpy doesn't do that (saves effort, and saves repo space).

Size per release:

$ cd /srv/docs_scipy_org/doc
$ ls -lh scipy-1.15.0/
total 71M

Number of releases we store:

ls
README.html    numpy-1.10.0  numpy-1.15.0       numpy-1.6.0    scipy-0.10.0  scipy-0.16.1       scipy-0.9.0   scipy-1.12.0  scipy-1.16.1  scipy-1.4.1  scipy-1.7.0    scipy-ref-1.8.0.pdf
_images        numpy-1.10.1  numpy-1.15.1       numpy-1.7.0    scipy-0.10.1  scipy-0.17.0       scipy-1.0.0   scipy-1.13.0  scipy-1.16.2  scipy-1.5.0  scipy-1.7.1    scipy-ref-1.8.1.pdf
_sources       numpy-1.10.4  numpy-1.15.4       numpy-1.8.0    scipy-0.11.0  scipy-0.17.1       scipy-1.1.0   scipy-1.13.1  scipy-1.2.0   scipy-1.5.1  scipy-1.8.0    tutorial
_static        numpy-1.11.0  numpy-1.16.0       numpy-1.8.1    scipy-0.12.0  scipy-0.18.0       scipy-1.10.0  scipy-1.14.0  scipy-1.2.1   scipy-1.5.2  scipy-1.8.1
_templates     numpy-1.12.0  numpy-1.16.1       numpy-1.9.0    scipy-0.13.0  scipy-0.18.1       scipy-1.10.1  scipy-1.14.1  scipy-1.2.3   scipy-1.5.3  scipy-1.9.0
dev            numpy-1.13.0  numpy-1.17.0       numpy-1.9.1    scipy-0.14.0  scipy-0.19.0       scipy-1.11.0  scipy-1.15.0  scipy-1.3.0   scipy-1.5.4  scipy-1.9.1
download.html  numpy-1.14.0  numpy-1.3.x        numpy-1.9.2    scipy-0.14.1  scipy-0.19.1       scipy-1.11.1  scipy-1.15.1  scipy-1.3.1   scipy-1.6.0  scipy-1.9.2
error.html     numpy-1.14.1  numpy-1.4.x        numpy-1.9.3    scipy-0.15.0  scipy-0.7.x        scipy-1.11.2  scipy-1.15.2  scipy-1.3.2   scipy-1.6.1  scipy-1.9.3
external       numpy-1.14.2  numpy-1.5-chm.zip  numpy-chm.zip  scipy-0.15.1  scipy-0.8-chm.zip  scipy-1.11.3  scipy-1.15.3  scipy-1.3.3   scipy-1.6.2  scipy-chm.zip
index.html     numpy-1.14.5  numpy-1.5.x        scipy          scipy-0.16.0  scipy-0.8.x        scipy-1.11.4  scipy-1.16.0  scipy-1.4.0   scipy-1.6.3  scipy-dev

We could decide to store only docs the last 10 feature releases, reshuffle the repo when we hit 11 by dropping the oldest set of docs, and use GitHub Pages. That saves maintenance effort of the server and hitting a problem there once a year or so.

As for the server itself, Enthought - with @dpinte the point person, and one of their sysadmins helped out regularly in the past too - has been maintaining it for us for many years, which is much appreciated.

Server maintenance can be a painful chore, and when there's a problem it's usually not at a convenient time. We migrated https://scipy.org/ and the mailing list away from that server years ago; the docs are so bulky that it has been harder to make that decision. I think we can investigate the current issue, or choose static hosting, or perhaps put a CDN in front to patch over the problem if we can't find it. Migrating the current setup to a new server unchanged and taking on admin responsibility seems like the least attractive of all the options.

I'm not seeing problems right now by the way. The site won't be as responsive as https://scipy.github.io/devdocs/ (because that's on GitHub pages rather than a lone Apache server), but it seems to function fine. If someone sees unusual latencies, it'd be great to post some stats here.

@dpinte

I don't think we should do a migration to a new server if we don't understand the problem. The current setup has its issues with deployment, but it works the way it works for a reason.

I agree - the best solution is to understand what's broken before any fixes are attempted.

I wrote a document on troubleshooting steps that I think might help. If there's anyone who has the time/access to try them, that would be great.

We had numpy docs on there as well until 2020. We migrated those to static deployment with GitHub Pages, using the https://github.com/numpy/doc repo. That is the alternative here I'd say. The issue with that is that the repo size grows with every minor release. Repo size can be up to 1 GB, for NumPy it's now 400 MB or so - see numpy/numpy#24736 for the latest discussion. The math is fairly simple (I can't find the previous issue about this so quickly, if anyone remembers please post a link). scipy docs are larger than numpy docs, so we can grow it for O(5 years) until we have to reshuffle the repo. Maybe that is the right option now, not sure.

[...]

I think we can investigate the current issue, or choose static hosting, or perhaps put a CDN in front to patch over the problem if we can't find it. Migrating the current setup to a new server unchanged and taking on admin responsibility seems like the least attractive of all the options.

As an alternative to running a server, what would you think about hosting the docs on a Cloudflare R2 bucket with a custom domain? This is an S3-like object storage service. We could optionally put a Cloudflare CDN in front of that.

In terms of cost, this would cost $0.20 per month for storage, plus $0.36 per million HTTP requests. (See pricing.) The workflow for updating the docs would also change: instead of rsyncing to a cloud server, a release manager would use rclone or an S3 compatible client. (Alternatively, the update could be made through a GitHub action triggered by a push to a maintenance branch.)

This would have the advantage of providing unlimited storage space, so we wouldn't need to delete old docs. I see the old docs as being worth the expense.

I'm not seeing problems right now by the way. The site won't be as responsive as https://scipy.github.io/devdocs/ (because that's on GitHub pages rather than a lone Apache server), but it seems to function fine. If someone sees unusual latencies, it'd be great to post some stats here.

Here's an update to the monitoring statistic that I posted last week. Latency has improved, but average uptime has dropped to 97% over the past 24 hours.

If anyone is interested in live updates to this monitor, I have added a status page here: https://stats.uptimerobot.com/oKUpNEbIwJ

As for the server itself, Enthought - with @dpinte the point person, and one of their sysadmins helped out regularly in the past too - has been maintaining it for us for many years, which is much appreciated. Server maintenance can be a painful chore, and when there's a problem it's usually not at a convenient time.

I agree. I've worked on this project for less than a year. I am not familiar with the history of the project, and the hard work that many volunteers have put into running the services that the SciPy community depends on. I am sorry if I came across as unappreciative in my previous comment. I do appreciate the work that Enthought and @dpinte have put into this server.

We have a habit of uploading new docs for every bug fix release though, and that seems unnecessary - numpy doesn't do that (saves effort, and saves repo space).

Ok, noted. Maybe in the distant future when O(5 lines) change in the docs there will be a way to effectively update the docs in an efficient diff/git-like manner that doesn't require copying everything up again.

That said, a lot of us are probably more excited about writing a new algorithm for SciPy or similar, which is already hard to find time for even with partial funding, which probably gets back to the original comment about avoiding new server burdens.

@dpinte

I am sorry if I came across as unappreciative in my previous comment

You didn't! Thanks for digging into the current issue so thoroughly 🙏🏼

I wrote a document on troubleshooting steps that I think might help. If there's anyone who has the time/access to try them, that would be great.

I just ran all of those steps. A few tools aren't installed, and I don't have enough permissions to look at the access log. Hopefully there is something in there that is helpful:

Details

$ uptime
 08:55:15 up 7 days, 20:38,  1 user,  load average: 0.26, 0.24, 0.20

$ dmesg | tail
[678954.662573] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=112.39.177.108 DST=172.20.0.86 LEN=40 TOS=0x04 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=24134 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[678974.690009] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=183.254.39.31 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=0 DF PROTO=TCP SPT=14315 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[678995.230984] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=139.162.112.248 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=TCP SPT=44350 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679014.695091] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.26 DST=172.20.0.86 LEN=40 TOS=0x04 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=3145 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679034.923413] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.197.81 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=7400 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679054.861974] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.26 DST=172.20.0.86 LEN=40 TOS=0x04 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=3202 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679074.726640] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.26 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=43 ID=0 DF PROTO=TCP SPT=3519 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679094.764122] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.54 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=25050 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679114.894849] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.26 DST=172.20.0.86 LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=17664 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
[679134.740880] [UFW BLOCK] IN=eth0 OUT= MAC=0a:20:33:fc:6d:08:0a:df:6f:8c:1a:94:08:00 SRC=223.101.196.26 DST=172.20.0.86 LEN=40 TOS=0x04 PREC=0x00 TTL=44 ID=0 DF PROTO=TCP SPT=17835 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 

$ vmstat 1 --unit M
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0     73     60   1496    0    0  4782    51   10   22  9 13 67  1  9
 3  0      0     83     59   1485    0    0  9548     0 3796  996  4 11 81  3  1
 0  0      0     77     59   1492    0    0  6484    48 3800 1099  7 15 75  2  1
 0  0      0     83     57   1484    0    0 11252     0 3735  797 13 10 74  3  0
 0  0      0     77     57   1491    0    0  7320    48 3534  896  3 12 79  3  2
 0  0      0     87     56   1482    0    0 11184     0 3491  973  9  8 79  4  0
 4  0      0     76     56   1490    0    0  8380     0 4010 1091 10 18 69  3  0
 0  0      0     87     55   1478    0    0  9476    20 3802 1075 13 14 69  3  1
 0  0      0     81     56   1486    0    0  8448   284 3809  859 11 11 76  2  1
 1  0      0     71     56   1495    0    0  9800     0 3396  908  7 10 79  4  0
 0  0      0     82     56   1482    0    0  8768    76 3431  782  3 12 79  4  1
 0  0      0     75     56   1488    0    0  6340     0 3588  841  5  9 82  2  1
 0  0      0     70     56   1495    0    0  6588    24 3785  922  2 15 81  2  0
 1  0      0     87     56   1481    0    0  7224     0 3667 1051  6 12 77  4  1
 0  0      0     76     56   1489    0    0  8104     0 3779  847 17  8 72  2  1
 0  0      0     72     56   1495    0    0  6672    76 3824  831  6 13 78  3  0
 2  0      0     83     55   1484    0    0  8476     0 3798 1000  5 13 78  3  1
 0  1      0     79     56   1490    0    0  6656    12 3722  866  7 10 78  3  1
 0  1      0     71     56   1497    0    0  6964     0 3767 1027  5 13 79  3  0
 1  0      0     81     55   1486    0    0 10108     0 3857  956  6 12 76  5  1
 0  0      0     71     56   1494    0    0  8516    24 4030  852  5  9 82  3  1
 0  0      0     88     55   1479    0    0  5796    80 3932  820  3 11 83  3  0
 0  0      0     80     55   1488    0    0  9840     0 4022  965  3  9 82  4  1
 0  0      0     78     56   1494    0    0  6768   228 3919  778  4 11 80  3  1

$ mpstat -P ALL 1
The program 'mpstat' is currently not installed. To run 'mpstat' please ask your administrator to install the package 'sysstat'

$ pidstat 1
The program 'pidstat' is currently not installed. To run 'pidstat' please ask your administrator to install the package 'sysstat'

$ iostat -xz 1
The program 'iostat' is currently not installed. To run 'iostat' please ask your administrator to install the package 'sysstat'

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           1998         340          80          24        1577        1423
Swap:             0           0           0

$ sar -n DEV 1
The program 'sar' is currently not installed. To run 'sar' please ask your administrator to install the package 'sysstat'

$ top
top - 08:58:28 up 7 days, 20:41,  1 user,  load average: 0.47, 0.30, 0.22
Tasks: 120 total,   1 running, 119 sleeping,   0 stopped,   0 zombie
%Cpu(s): 15.5 us,  2.5 sy,  0.0 ni, 70.1 id,  2.5 wa,  0.0 hi,  8.8 si,  0.7 st
KiB Mem :  2046372 total,    71760 free,   367984 used,  1606628 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1438244 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                               
 7145 www-data  20   0 2377660  46356  11804 S 12.3  2.3   0:04.14 apache2                                                                                                               
 7438 www-data  20   0 2453592  47664   8404 S  5.6  2.3   0:05.06 apache2                                                                                                               
    3 root      20   0       0      0      0 S  0.3  0.0 181:33.54 ksoftirqd/0                                                                                                           
    7 root      20   0       0      0      0 S  0.3  0.0  26:29.16 rcu_sched                                                                                                             
   30 root      20   0       0      0      0 S  0.3  0.0 220:07.57 kswapd0                                                                                                               
 2142 root      20   0  116072  12768   3028 S  0.3  0.6  27:03.28 nessus-agent-mo                                                                                                       
 5854 www-data  20   0 2323820  26016   8580 S  0.3  1.3   0:07.70 apache2                                                                                                               
 6342 rgommers  20   0   94856   4140   3120 S  0.3  0.2   0:00.46 sshd                                                                                                                  
    1 root      20   0  119444   4792   3164 S  0.0  0.2   0:18.00 systemd        

$ ss -s
Total: 482 (kernel 0)
TCP:   523 (estab 191, closed 276, orphaned 5, synrecv 0, timewait 274/0), ports 0

Transport Total     IP        IPv6
*	  0         -         -        
RAW	  0         0         0        
UDP	  2         2         0        
TCP	  247       4         243      
INET	  249       6         243      
FRAG	  0         0         0  

$ wc -l /var/log/apache2/access.log
wc: /var/log/apache2/access.log: Permission denied

As an alternative to running a server, what would you think about hosting the docs on a Cloudflare R2 bucket with a custom domain?

That seems like a good option potentially. It'd be nice to get a sense for the number of requests/month, since that'll be most of the cost. I just tried some free website analytics tools, but that gives very little info. Counting lines in /var/log/apache2/access.log seems easiest, maybe you can do that @dpinte?

Same for MNE-Python, today has been a particularly bad day for it (I would say over half my CI runs have died on the intersphinx resolution, but not all of them). Maybe knowing that is useful for log pulls or something!

@nickodell

@nickodell @jychuah suggestions?

@nickodell @jychuah suggestions?

The major suggestion I would make to fix builds is to get the file from static.scipy.org, our static file hosting.

Add this to your sphinx configuration file:

intersphinx_mapping = {
    "scipy": ("https://docs.scipy.org/doc/scipy/", "https://static.scipy.org/doc/scipy/objects.inv"),
}

The inventory file https://static.scipy.org/doc/scipy/objects.inv is equivalent to https://docs.scipy.org/doc/scipy/objects.inv. This file is automatically mirrored to static.scipy.org by a cron job on docs.scipy.org every hour, and it is served from more reliable infrastructure (R2.)

Okay opened Quansight-Labs/intersphinx_registry#123 for those of us using intersphinx_registry!

docs: fetch the scipy intersphinx inventory from a CDN-backed mirror

docs: fetch the scipy intersphinx inventory from a CDN-backed mirror (#…

docs: use static.scipy.org mirror for scipy intersphinx

@nickodell

Add this to your sphinx configuration file:

intersphinx_mapping = {
    "scipy": ("https://static.scipy.org/doc/scipy/", None),
}

@nickodell unfortunately it doesn't work, because while the docs build fine (objects.inv is served), the generated links all get wrong and point to https://static.scipy.org/doc/scipy/. As an example, see the "See also" link in this CuPy doc that is built with this suggestion: https://docs.cupy.dev/en/latest/reference/generated/cupyx.scipy.interpolate.BarycentricInterpolator.html#cupyx.scipy.interpolate.BarycentricInterpolator.

cc @rgommers @seberg for vis

It seems Qiskit's tweaks would fix the base url issue, we're looking into it: Qiskit/qiskit-fermions#319

@leofang

@nickodell unfortunately it doesn't work, because while the docs build fine (objects.inv is served), the generated links all get wrong and point to https://static.scipy.org/doc/scipy/.

@leofang Thank you for the correction. I'd forgotten that this also determines the base URL of the documentation. Here's a fixed version that splits the INV file (which we mirror) from the HTML (which we do not.)

intersphinx_mapping = {
    "scipy": ("https://docs.scipy.org/doc/scipy/", "https://static.scipy.org/doc/scipy/objects.inv"),
}

This will generate sphinx docs where the target is set to the stable docs at https://docs.scipy.org/doc/scipy/.

cc @larsoner for intersphinx

docs: point scipy intersphinx target back at docs.scipy.org

cc @larsoner for intersphinx

Fixed, merged and published.

should we be advertising this fix in a better place than buried in this thread?

Navigation Menu

Repository navigation

Website performance issues #102

126 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Website performance issues #102

Description

Activity

nickodell commented on Oct 10, 2025

tylerjereddy commented on Oct 11, 2025

dpinte commented on Oct 12, 2025

dpinte commented on Oct 12, 2025

Carreau commented on Oct 17, 2025

tupui commented on Oct 17, 2025

dpinte commented on Oct 17, 2025

nickodell commented on Oct 17, 2025

dpinte commented on Oct 17, 2025

Carreau commented on Oct 18, 2025

rgommers commented on Oct 18, 2025

rgommers commented on Oct 18, 2025

nickodell commented on Oct 18, 2025

tylerjereddy commented on Oct 18, 2025

rgommers commented on Oct 20, 2025

126 remaining items

larsoner commented on Sep 3, 2026

tylerjereddy commented on Sep 3, 2026

nickodell commented on Sep 4, 2026

larsoner commented on Sep 4, 2026

leofang commented on Sep 4, 2026

leofang commented on Sep 4, 2026

nickodell commented on Sep 4, 2026

Carreau commented on Sep 5, 2026

lucascolley commented on Sep 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions