Skip to content

Don't include absolute paths when using --embed-positions#6755

Merged
da-woods merged 8 commits intocython:masterfrom
tobiasdiez:embed-pos-relative
Feb 2, 2026
Merged

Don't include absolute paths when using --embed-positions#6755
da-woods merged 8 commits intocython:masterfrom
tobiasdiez:embed-pos-relative

Conversation

@tobiasdiez
Copy link
Copy Markdown
Contributor

Currently, invoking cython with embed-positions from a folder not containing the source code, will result in the absolute paths being embedded. This is fixed by always embedding the relative paths.

Since there are a couple of places where a relative path of a SourceDescriptor is needed, a new method get_relative_path is introduced and reused.

Copy link
Copy Markdown
Contributor

@scoder scoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you always call .as_posix() on the return value of get_relative_path(). So, why return a pathlib.Path instead of a plain string directly?

Comment on lines +287 to 292
def get_relative_path(self):
return Path(self.get_description())

get_error_description = get_description

def get_filenametable_entry(self):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We previously used "stringsource>" here and you changed it to self.name. Why?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how the previous code worked in this regard. If you would use stringsource> here, then above in the Compilor/<x>Nodes you would call Path("stringsource>") which doesn't look right. I suspect that it got filtered out by the isabs check, which then falls back to the description > name.

Co-authored-by: scoder <stefan_ml@behnel.de>
@tobiasdiez
Copy link
Copy Markdown
Contributor Author

@scoder Anything left to do here?

vbraun pushed a commit to vbraun/sage that referenced this pull request Sep 16, 2025
sagemathgh-40686: Install pyx sources with meson
    
Currently the meson build doesn't install the pyx source files, as
opposed to the setuptools build. This has caused/is causing several
issues:
- The method `sage_getsource` as well as ipython's own source viewer
`??` don't work for cython methods. This creates an inconsistency with
python methods, and breaks several tests when the sage source is not
available (eg. distro packages).
- It breaks the doc builder
sagemath#39973 (comment)
- It used to cause issues when accessing some methods
(sagemath#39735), now worked around.

The only reason why these issues are not present in sage-the-distro is
that cython wrongly embeds the absolute paths of source files, which
masks the issues as long as the source is present in its original
location. But as soon as cython/cython#6755 is
released this will affect all types of sage build.

In any case, I believe being able to inspect the methods implementation
from the sage interface itself is a valuable feature for mathematicians,
which are its main user base.

I have only done one dir so far so I don't waste my time in case this is
rejected or a different implementation is proposed. I will do the rest
when I get the OK.

Fixes sagemath#39874
    
URL: sagemath#40686
Reported by: Antonio Rojas
Reviewer(s): Tobias Diez
vbraun pushed a commit to vbraun/sage that referenced this pull request Sep 19, 2025
sagemathgh-40686: Install pyx sources with meson
    
Currently the meson build doesn't install the pyx source files, as
opposed to the setuptools build. This has caused/is causing several
issues:
- The method `sage_getsource` as well as ipython's own source viewer
`??` don't work for cython methods. This creates an inconsistency with
python methods, and breaks several tests when the sage source is not
available (eg. distro packages).
- It breaks the doc builder
sagemath#39973 (comment)
- It used to cause issues when accessing some methods
(sagemath#39735), now worked around.

The only reason why these issues are not present in sage-the-distro is
that cython wrongly embeds the absolute paths of source files, which
masks the issues as long as the source is present in its original
location. But as soon as cython/cython#6755 is
released this will affect all types of sage build.

In any case, I believe being able to inspect the methods implementation
from the sage interface itself is a valuable feature for mathematicians,
which are its main user base.

I have only done one dir so far so I don't waste my time in case this is
rejected or a different implementation is proposed. I will do the rest
when I get the OK.

Fixes sagemath#39874
    
URL: sagemath#40686
Reported by: Antonio Rojas
Reviewer(s): Tobias Diez
@antonio-rojas
Copy link
Copy Markdown

Ping. Having this merged is important to fix issues with the meson build of sagemath.

@dkwo
Copy link
Copy Markdown

dkwo commented Jan 14, 2026

@tobiasdiez Do you think you can rebase this patch? For me, it does not apply cleanly on top of 3.2.4.

@tobiasdiez
Copy link
Copy Markdown
Contributor Author

@dkwo it says there are no conflicts with the the base branch, so if you take the whole branch as a patch it should apply cleanly.

@scoder could we please get this in?

@dkwo
Copy link
Copy Markdown

dkwo commented Jan 15, 2026

For me it does not apply cleanly on top of master branch: I had to edit by hand a few changes to Scanning file.
Hopefully it will get merged soon, and thanks!

Copy link
Copy Markdown
Contributor

@da-woods da-woods left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me.

My main worry is that I don't quite know where all these paths are actually used. I think we have:

  • code objects (probably mostly cosmetic but I imagine some people are using them in debugger type tools)
  • tracebacks (again, mostly cosmetic but not helpful if they break)
  • docstrings (mostly cosmetic, probably some people using them. I think this is what sage is trying to use)

My view is that we should probably merge it into the master branch (on the basis that it's consistent with what we try to do generally) and see if it causes any issues. But it's definitely the sort of change that feels a bit like it's going to cause unexpected problems.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably want to remove these - I think they're both unused (although isabs was used before your change)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, removed them.

@da-woods da-woods added this to the 3.3 milestone Feb 2, 2026
@da-woods da-woods merged commit d344f9b into cython:master Feb 2, 2026
89 checks passed
@da-woods
Copy link
Copy Markdown
Contributor

da-woods commented Feb 2, 2026

Thanks. I think it makes sense to merge this and see how it works.

@tobiasdiez
Copy link
Copy Markdown
Contributor Author

Thanks for the review and merge!

@tobiasdiez tobiasdiez deleted the embed-pos-relative branch February 3, 2026 00:23
matusvalo pushed a commit to matusvalo/cython that referenced this pull request Feb 7, 2026
)

Currently, invoking cython with `embed-positions` from a folder not
containing the source code, will result in the absolute paths being
embedded. This is fixed by always embedding the relative paths.

Since there are a couple of places where a relative path of a
`SourceDescriptor` is needed, a new method `get_relative_path` is
introduced and reused.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants