Maintain speed.python.org and speed.pypy.org from a single branch #100

Activity

1. StanFromIreland

   self-assigned this

   on Nov 3, 2026
2. StanFromIreland commented on Nov 3, 2026

   

   StanFromIreland

   on Nov 3, 2026

   Last edited by StanFromIreland

   MemberAuthor

   More actions

   Thankfully, it didn't take that long. The merged branch is up at https://github.com/python/codespeed/tree/main. It primarily takes codespeed/ from PyPy. Each site is now just its settings package on top of the shared app, reducing the maintenance burden.

   @mattip could you pleas try it for speed.pypy.org? It should look pretty much the same as today (I did some testing of both sites, and I'm happy with the few little improvements). A few little things changed, namely:

   • Some new settings keep PyPy's defaults: TIMELINE_GRID_REVISIONS and COMP_ENVIRONMENTS_DEFAULT.
   • The "All/None" links are back on the comparison page's environment list (and they now actually redraw the chart when clicked).
   • Benchmark grouping by source is data dependant so that with two sources you get the Legacy/PyPerformance headers but a site with one source gets a regular list.
   • Fixed a little bug with report tables cached before the source migration, since they have no bench_source per row, so changes_table.html silently rendered an empty table for them. get_changes_table now rebuilds such caches once.
   • requirements.txt no longer pins django<4, so the deploy will upgrade Django.

   If you're happy, we can merge python/psf-salt#673 to deploy both sites from main, and then retire the two branches. :-) Before that, once I get access to the server, I'll dump the databases and save a copy, just in case anything goes awry.
3. mattip commented on Nov 4, 2026

   

   mattip

   on Nov 4, 2026

   More actions

   How does each site get its own speed_python/local_settings.py?
4. mattip commented on Nov 4, 2026

   

   mattip

   on Nov 4, 2026

   More actions

   As for access to the server, I added a dumpdb button to the admin page. Is that preserved?
5. StanFromIreland commented on Nov 4, 2026

   

   StanFromIreland

   on Nov 4, 2026

   MemberAuthor

   More actions

   You should be able to add a local_settings.py, I didn't have any issue? And yes, the dump button is preserved (and added to speed.python.org).
6. mattip commented on Nov 4, 2026

   

   mattip

   on Nov 4, 2026

   More actions

   I wasn’t clear, sorry. I don’t understand the plan. We cannot deploy both sites from the same commit with the same local_settings.py, they have to be differentiated somehow. What do you propose to do that?
7. diegorusso commented on Nov 4, 2026

   

   diegorusso

   on Nov 4, 2026

   Last edited by diegorusso

   More actions

   /makeimage/ has a regression relative to speed.python.org: 198718a moved return response out of makeimage() and into about(), after an unconditional return. For a valid request, the PNG is generated, but the view returns None, so Django raises ValueError and responds with HTTP 500.

   I reproduced this locally on main (80367db); the same request returns a PNG on the Python branch. The return response needs to go back at the end of makeimage().

   The rest seems OK, good stuff!
8. diegorusso commented on Nov 4, 2026

   

   diegorusso

   on Nov 4, 2026

   Last edited by diegorusso

   More actions

   I wasn’t clear, sorry. I don’t understand the plan. We cannot deploy both sites from the same commit with the same local_settings.py, they have to be differentiated somehow. What do you propose to do that?

   IIRC, local_settings.py is not checked in and belongs to the machine. The content is specific to your configuration.
9. StanFromIreland commented on Nov 4, 2026

   

   StanFromIreland

   on Nov 4, 2026

   MemberAuthor

   More actions

   /makeimage/ has a regression relative to speed.python.org: 198718a moved return response out of makeimage() and into about(), after an unconditional return. For a valid request, the PNG is generated, but the view returns None, so Django raises ValueError and responds with HTTP 500.

   Thanks and good catch, I've pushed a fix. This was originally a regression on the PyPy branch which I then pulled in (an example of why deduplicating would be useful).

   We cannot deploy both sites from the same commit with the same local_settings.py, they have to be differentiated somehow. What do you propose to do that?

   Sorry, I answered the wrong question. The differentiation is the settings package, not the commit/branch. main has both speed_python/ and speed_pypy/, each with its own committed settings.py, urls.py, templates etc., so your speed_pypy/settings.py is in the tree as before. Each one ends with from .local_settings import *, so your machine-specific values live in speed_pypy/local_settings.py, as they do today. Which site runs is picked by the entry point, psf-salt runs the PyPy instance from its own checkout with speed_pypy.wsgi:application and writes its local_settings.py into speed_pypy/ (locally it is --settings=speed_pypy.settings). Same repository and branch, but two settings packages and two local settings files.
10. mattip commented on Nov 4, 2026

    

    mattip

    on Nov 4, 2026

    More actions

    LGTM. Thanks @StanFromIreland this will simplify maintenance going forward.

    ❤️React with ❤️1Reacted by Stan Ulbrych
11. mattip commented on Nov 4, 2026

    

    mattip

    on Nov 4, 2026

    More actions

    I will in the future be updating speed.pypy.org's home page to show graphs from both legacy and pyperformance benchmarks, but that will live in the speed_pypy directory
12. StanFromIreland commented on Nov 4, 2026

    

    StanFromIreland

    on Nov 4, 2026

    MemberAuthor

    More actions

    I will in the future be updating speed.pypy.org's home page to show graphs from both legacy and pyperformance benchmarks, but that will live in the speed_pypy directory

    Sounds good. We should keep PyPy/CPython specific views to their directory (I did that for the geo-mean trend graph, for example).