File: Add full_path() method

[xclaesse]

This is needed now that str.format() is not allowing it any more. It is also more consistent with other objects that have that method as well, such as build targets.

Fixes: #12406

[anarazel]

Awesome. I'm afk most of the day today, but will try this tonight or tomorrow.

[tristan957]

mypy failing

[eli-schwartz]

This is needed now that str.format() is not allowing it any more.

Untrue. The change in str.format() is totally irrelevant since they don't even do the same thing, "not even mostly".

It is also more consistent with other objects that have that method as well, such as build targets.

Also untrue. Other objects do not have statically known-at-authorship-time names. In particular, executables and libraries can have absolutely any name at all because meson chooses file extensions itself based on the platform (and there's no actual way to tell what that is going to be).

To the extent that str.format was ever useful or accomplished any task whatsoever, the fs module's fs.name() function achieves precisely the same goal. More generally it sort of feels to me like the fs module is a more elegant approach to the problem domain. I've wondered a time or two whether we should deprecate full_path and replace it with fs module APIs, actually.

[tristan957]

@eli-schwartz I will post a PR for adding support to various types to the fs module. Maybe we can land it for 1.3 if I am quick enough.

[anarazel]

Hi,

This is needed now that str.format() is not allowing it any more.

Untrue. The change in str.format() is totally irrelevant since they don't even do the same thing, "not even mostly".

How is it not relevant that you invented a new kind of deprecations - which do not respect minimum_version and warn at every callsite) - preventing meson users from using str.format('@0@'.some-file), which previously worked (albeit undocumented and sometimes perhaps unpredictable), without providing a documented replacement so far? Due to not respecting minimum_version, and due to warning in several places instead of just one, there's obviously (presumably intentionally) pressure to find another solution.

I really don't understand why the use of str.format() of other types is worth going this extra mile just to break peoples use of meson. "Project uses feature that was always broken" - it just wasn't, it obviously worked for some purposes. It was ugly, it perhaps had downsides. But it wasn't "always broken".

To the extent that str.format was ever useful or accomplished any task whatsoever, the fs module's fs.name() function achieves precisely the same goal.

From what I can tell fs.name(file) is just as undocumented as str.format('@0@', file) is/was. I just learned about it apparently accepting file in your comment above, not in #12406, not when I asked on IRC a couple times.

More generally it sort of feels to me like the fs module is a more elegant approach to the problem domain. I've wondered a time or two whether we should deprecate full_path and replace it with fs module APIs, actually.

Maybe - but I think it'd need a new function to be comparable. Needing to replace foo.full_path() with fs.parent(foo) / fs.name(foo) or fs.relative_to(foo, meson.current_build_dir()) doesn't strike me as an improvement.

Greetings,

Andres

[anarazel]

Awesome. I'm afk most of the day today, but will try this tonight or tomorrow.

@xclaesse Tried the PR out, worked without a problem here!

[eli-schwartz]

How is it not relevant that you invented a new kind of deprecations - which do not respect minimum_version and warn at every callsite) - preventing meson users from using str.format('@0@'.some-file), which previously worked (albeit undocumented and sometimes perhaps unpredictable), without providing a documented replacement so far? Due to not respecting minimum_version, and due to warning in several places instead of just one, there's obviously (presumably intentionally) pressure to find another solution.

Adding a new deprecation for something that "never worked reliably or correctly" is a matter of warning people that we cannot and will not commit to it working, nor ever did. It does not imply that there's a replacement. There doesn't have to be a replacement. There is nothing wrong with a replacement existing, but it isn't inherent to the nature of issuing a deprecation warning if we genuinely believe that something as it is today is broken. Adding a replacement is a separate concern -- it is adding new functionality that, frankly, never existed before.

We've deprecated many things other than files() objects here -- lots of things that don't have replacements, and aren't being proposed for replacement here, but which actually used to dump really badly formatted python repr()s.

Of course there is pressure to find another solution. But remember that previously existing build files are not supposed to break as a result of this change. Issuing a warning doesn't cause builds to fail. I believe this is a very important distinction.

Mostly, what I'm trying to point out is that this proposed feature should be considered on its own merit (and I agree it has independent merit).

From what I can tell fs.name(file) is just as undocumented as str.format('@0@', file) is/was. I just learned about it apparently accepting file in your comment above, not in #12406, not when I asked on IRC a couple times.

The fs module documentation is module documentation -- this means that it doesn't have as nice function signature docs as the non-module functions, as those never got migrated. However, it is documented (using prose):

Since 0.59.0, all functions accept files() objects if they can do something useful with them (this excludes exists, is_dir, is_file, is_absolute since a files() object is always the absolute path to an existing file).

I should note that fs.as_posix() doesn't support files objects either, and it seems to be ambiguous whether it "can do something useful with them" but isn't explicitly called out here as not supporting it.

Maybe - but I think it'd need a new function to be comparable. Needing to replace foo.full_path() with fs.parent(foo) / fs.name(foo) or fs.relative_to(foo, meson.current_build_dir()) doesn't strike me as an improvement.

Yes, sorry for not making myself clear -- I actually did mean I've thought about adding new fs module APIs for this, not asking people to combine fs.name + fs.parent

[tristan957]

Are you thinking like an fs.path() function Eli?

[xclaesse]

I'm not sure to understand in which world it makes more sense to use a fs module function rather than a method on the object itself. Especially since we already have full_path() on other object types (build target, custom target, programs).

[jpakkane]

I agree having it as a method is cleaner. Because otherwise if you just want to get the path you potentially have to do

fs = import('fs')
something(fs.path(other))

as opposed to the one-liner

something(other.full_path())

[jpakkane]

Test failure is relevant:

mesonbuild.interpreterbase.exceptions.InterpreterException: Assert failed: prog0[0].full_path() == meson.current_source_dir() / 'prog.c'

[jpakkane]

That should probably be:

prog0[0].full_path() == (meson.current_source_dir() / 'prog.c').full_path()

[xclaesse]

I think the problem in the test case is the / operator returns a string where \ is replaced by /: os.path.join(this, other).replace('\\', '/'). That behavior is really inconsistent across Meson and has been annoying me a lot.