sage --package properties

[mkoeppe]

For example:

$ ./sage -package properties --format shell gap ecl                                                                                                                               git:sage_package_properties
path_ecl='/Users/mkoeppe/s/sage/sage-rebasing/worktree-pristine/build/pkgs/ecl'
version_with_patchlevel_ecl='21.2.1'
type_ecl='standard'
source_ecl='normal'
trees_ecl='SAGE_LOCAL'
path_gap='/Users/mkoeppe/s/sage/sage-rebasing/worktree-pristine/build/pkgs/gap'
version_with_patchlevel_gap='4.12.2'
type_gap='standard'
source_gap='normal'
trees_gap='SAGE_LOCAL'

The output is suitable as input for eval in Bourne shell. (The default output format is more human-friendly.)

Split out from:

• Refactor bootstrap-conda, m4/sage_spkg_collect.m4 through sage-package; handle dependencies_build #36740

where this new interface is used to eliminate direct references to build/pkgs/ from various scripts and reduce code duplication and complexity in reading SPKG metadata.

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

⌛ Dependencies

[kwankyu]

It would be natural to print like

$ ./sage -package properties gap                                                                                                                              
path='/Users/mkoeppe/s/sage/sage-rebasing/worktree-pristine/build/pkgs/gap'
version_with_patchlevel='4.12.2'
type='standard'
source='normal'
trees='SAGE_LOCAL'

Why accept multiple pac and add _pac?

[mkoeppe]

Why accept multiple pac and add _pac?

So that a shell script can request this information in bulk instead of invoking this script many times.
(In #36740, this gives a speedup in running ./configure)

[kwankyu]

Would you point where the suffixed string is used?

[mkoeppe]

In https://github.com/sagemath/sage/pull/36740/files#diff-b1f0deab6b85906bd925c4fceb337406ebea20bdc199c63996977328d24cf5c5R347, take a look at:

• m4/sage_spkg_collect.m4 line 155 SPKG_VERSION=$[version_with_patchlevel_]SPKG_NAME
• bootstrap line 58 eval DIR=\$path_$pkgname pkgtype=\$type_$pkgname pkgsource=\$source_$pkgname and similar

[kwankyu]

I see. You use the output directly to define variables...

I think the command should accommodate two uses: standalone and as pipeline.

[kwankyu]

How about adding an option --output=list and --output=vars with default the former? Thus

$ ./sage -package properties gap
gap:                                                                                                                              
  path='/Users/mkoeppe/s/sage/sage-rebasing/worktree-pristine/build/pkgs/gap'
  version_with_patchlevel='4.12.2'
  type='standard'
  source='normal'
  trees='SAGE_LOCAL'

$ ./sage -package properties --output=vars gap                                                                                                                              
path_gap='/Users/mkoeppe/s/sage/sage-rebasing/worktree-pristine/build/pkgs/gap'
version_with_patchlevel_gap='4.12.2'
type_gap='standard'
source_gap='normal'
trees_gap='SAGE_LOCAL'

[mkoeppe]

I'm open to creating output format options when needed (as you may have seen in #36740, sage --package dependencies has an option --format={plain,shell}), but I'm reluctant to add them without a specific use case

[kwankyu]

--format is okay.

A use case is just to read the output of ./sage -package properties gap by human eyes. This use is not expected?

[mkoeppe]

We already have a tool that formats package info for human inspection, that's sage -info SPKG...

[kwankyu]

But ./sage -package properties gap intends, as far as I understand, to provide other info (about installed packages) oriented for developers. That is a sage command, and developers may use them. If the command is only for shells, then why expose it as a sage command?

[mkoeppe]

./sage -package just delegates to sage-package, and ./sage -info just delegates to sage-spkg-info; both a provided by the Sage distribution. (But I feel I'm missing your point)

[kwankyu]

If the command is internal and not exposed to developers, I won't care the output format. But it is exposed and developers may use it and read the output, and then the output should be in a readable format. Currently the format is only suitable to shells. (I wonder if I misunderstand something...)

[mkoeppe]

OK, that makes sense, I'll add an option.

[mkoeppe]

How's this?

[kwankyu]

Thanks. Looks good to me.

[mkoeppe]

Thank you!

[vbraun]

Do all supported platforms use python3 as the "default" python? I'm getting:

Traceback (most recent call last):
  File "/var/lib/buildbot/slave/sage_git/build/build/bin/sage-package", line 40, in <module>
    from sage_bootstrap.cmdline import run
  File "/var/lib/buildbot/slave/sage_git/build/build/bin/../sage_bootstrap/cmdline.py", line 31, in <module>
    from sage_bootstrap.app import Application
  File "/var/lib/buildbot/slave/sage_git/build/build/bin/../sage_bootstrap/app.py", line 80
    def properties(self, *package_classes, props=['path', 'version_with_patchlevel', 'type', 'source', 'trees'],
                                               ^
SyntaxError: invalid syntax
************************************************************************
Error downloading tarball of ecl
************************************************************************

[mkoeppe]

Sorry about this. No, we still support python 2.7 as sage-bootstrap-python; see #35858.

[github-actions]

Documentation preview for this PR (built with commit b3be864; changes) is ready! 🎉