Vendor Textual

[lkollar]

Since this vendors the latest version of Textual which needs Python 3.9, this also drops support for 3.7 and 3.8 in Memray. If you think we should keep compatibility with those, we can downgrade Textual instead.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.45%. Comparing base (f552b35) to head (498105c).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #893      +/-   ##
==========================================
+ Coverage   92.44%   92.45%   +0.01%     
==========================================
  Files          99       98       -1     
  Lines       11726    11720       -6     
  Branches      426      423       -3     
==========================================
- Hits        10840    10836       -4     
+ Misses        886      884       -2     

Flag	Coverage Δ
cpp	92.45% <ø> (+0.01%)	⬆️
python_and_cython	92.45% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[godlygeek]

Ugh, I didn't think about the fact that we've been using different Textual versions on different Python versions, and this'll force us to use the same one across all of them. Blah.

[godlygeek]

OK. I think I'm comfortable dropping support for 3.7 and 3.8. Doing it because we're vendoring Textual feels stupid, but I can live with it... If we get pushback from users, one option might be to re-add support for 3.8 but make it so that it doesn't use the vendored copy, and instead has a dependency on Textual and uses the last version to support 3.8. It's only a little bit more work (updating all of our imports to be conditional based on sys.version_info and conditionally importing either the vendored version for 3.9+ or the real lib for 3.7 and 3.8).

@pablogsal Any objections to dropping 3.7 and 3.8 support?

[lkollar]

Out of curiosity I ran a query on the PyPI BigQuery dataset to see the version distribution for the past 30 days:

3.12  — 5,130,632  (33.23%)
3.10  — 4,512,845  (29.22%)
3.11  — 4,216,423  (27.31%)
3.13  — 1,270,580  (8.23%)
3.14  —   204,499  (1.32%)
3.9   —    84,772  (0.55%)
3.8   —    18,979  (0.12%)
3.7   —     2,831  (0.02%)
3.15  —       177  (0.00%)
2.7   —         1  (0.00%)
3.6   —         1  (0.00%)

Looks like 3.7 and 3.8 are barely used.

Here is the query for reference

WITH counts AS (
  SELECT
    REGEXP_EXTRACT(details.python, r'^\d+\.\d+') AS python_minor,
    COUNT(*) AS downloads
  FROM `bigquery-public-data.pypi.file_downloads`
  WHERE file.project = 'memray'
    AND DATE(timestamp) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
    AND details.python IS NOT NULL
  GROUP BY python_minor
)

SELECT
  python_minor,
  downloads,
  ROUND(downloads * 100.0 / SUM(downloads) OVER (), 2) AS pct
FROM counts
WHERE python_minor IS NOT NULL
ORDER BY downloads DESC

[godlygeek]

Out of curiosity I ran a query on the PyPI BigQuery dataset

Looks like 3.7 and 3.8 are barely used.

My concern is that big corporations are likely to continue using Python versions well past their end of life. Those big corporations will tend to be using PyPI mirrors, so I believe the entire company appears as only one download in the BigQuery dataset rather than thousands, if I understand how that data is gathered.

Even considering that I'm sure that the two older versions are our least used, but I do think that the BigQuery dataset likely underrepresents them.

[pablogsal]

No objections from me: drop 3.7 and 3.8. The PyPI data speaks for itself, and honestly those versions are so far past EOL that it's hard to justify the maintenance burden. Let's move on. 🚀