Skip to content

Conversation

@mcbarton
Copy link
Collaborator

@mcbarton mcbarton commented Nov 6, 2025

As far as I can tell these images are not being used anywhere in the repo, so this PR removes them.

@codecov-commenter
Copy link

codecov-commenter commented Nov 6, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.05%. Comparing base (5860e95) to head (da0796e).

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #404   +/-   ##
=======================================
  Coverage   82.05%   82.05%           
=======================================
  Files          21       21           
  Lines         858      858           
  Branches       89       89           
=======================================
  Hits          704      704           
  Misses        154      154           
🚀 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.

@mcbarton mcbarton force-pushed the Remove-unused-images branch 3 times, most recently from 37c8b49 to cb45bf3 Compare November 7, 2025 09:27
@mcbarton mcbarton force-pushed the Remove-unused-images branch from cb45bf3 to da0796e Compare November 10, 2025 09:35
@anutosh491
Copy link
Collaborator

Well xtensor stack (xtensor, xsimd, xtensor-blas etc) is like only set of repos for which we support fetching online documentation right now as can be seen from our link on the xeus-cpp-wasm repo.

image

So not mentioned anywhere but yeah probably that's the reason we had the xtensor image :\

@vgvassilev
Copy link
Contributor

Yes, but why is this different than other libraries?

@anutosh491
Copy link
Collaborator

anutosh491 commented Nov 10, 2025

Yes, but why is this different than other libraries?

I think that's because xeus-cling which was maintaining the responsible tagfiles for separate libraries as shown here (https://github.com/jupyter-xeus/xeus-cling/tree/main/etc/xeus-cling/tags.d). This is the not best approach right ? we don't want to host tagfiles for each library in our code.

Rather how xeus-cpp does it is, if a library author wants to support inline documentation through a notebook, they just need to generate and host tagfiles in their source itself and when we fetch the package the tagfiles land in our prefix from where we can use them.

I think Johan and I discussed this long back but yeah this can be improved on I think for sure ? Some kind of mechanism to generate the required files basically !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants