Add import_path to upgradeDepends directive.

[mauritsvanrees]

This avoids the need to register a full profile, when you only need to import a few files once in an upgrade step.

The path must be within the path of a package.
By default this is the path of the profile for which this is an upgrade.
You can also specify a path in a different package: other.package:profile/path.
This is to avoid easy information leaks, like trying to read password files, although the user running the zope process should not have access to sensitive files anyway.

You can combine this with import_steps, but not with import_profile.
Note that metadata.xml is never read, so you cannot use dependencies.

This adds the path keyword argument to several methods, like tool.runAllImportStepsFromProfile and tool.runImportStepFromProfile.

[d-maurer]

I do not like it much:

• special treatment of metadata.xml
• new tar support without mention in CHANGES.rst
• insufficient documentation for new parameter dependency_strategy

I would prefer alternatively an extended way to identify profiles: not only via registration names but also alternatively e.g. via a path. The different ways could be distinguished via prefixes.

[d-maurer]

GenericSetup has 2 kinds of dependencies: "step" and "profile" dependencies. To be specific, I suggest (profile) dependencies in place of dependencies.

Why do you treat metadata.xml specially? Would it not be more natural to view the new feature as just a different way to refer to a profile including the treatment of metadata.xml (if it exists).

Profile ids have the form profile-package:name. This suggests a path alternative of the form path-package:path. It would allow to universally specify profiles via paths: no need to add an additional parameter to several methods, no need to treat metadata.xml specially, True, the parameter profile_id would with this extension better have the name profile_spec, but I think a documentation note of the form: a "profile id" has either the form profile-... or path-... would be sufficient to explain the a profile can be identified either via a registered profile name or a file system path.

[mauritsvanrees]

GenericSetup has 2 kinds of dependencies: "step" and "profile" dependencies. To be specific, I suggest (profile) dependencies in place of dependencies.

That is indeed clearer. Fixed.

Why do you treat metadata.xml specially? Would it not be more natural to view the new feature as just a different way to refer to a profile including the treatment of metadata.xml (if it exists).

The same is true for the already existing import from tar archives. A metadata.xml in there is ignored. This file is only read when registering a profile.

I sometimes wished this was different: when you edit metadata.xml of a standard profile, you have to restart your instance, otherwise it has no effect. That could be something for a different PR.

Here the idea is: if you want metadata, then you should use a standard profile.
I would use this new feature to ease upgrading. Instead of a metadata.xml, I would just add an upgradeDepends for each other profile that I need. The other two items you could add in metadata.xml are version and description, both of which we don't need.

Profile ids have the form profile-package:name. This suggests a path alternative of the form path-package:path. It would allow to universally specify profiles via paths: no need to add an additional parameter to several methods, no need to treat metadata.xml specially, True, the parameter profile_id would with this extension better have the name profile_spec, but I think a documentation note of the form: a "profile id" has either the form profile-... or path-... would be sufficient to explain the a profile can be identified either via a registered profile name or a file system path.

That could be an option. I could try that.

[d-maurer]

I suggest to remove the new path parameter and to extend instead the notion of a profile id like this:

'profile_id` has either
the form 'profile-*package*:*name*' where *name* is the name of a profile registration for *package*
or the form 'path-*package*:*subpath*' where *subpath* is a path relative to the directory of *package*.

Similar suggestions for other methods.

[d-maurer]

Please specify the supported integer values and what they mean.

[d-maurer]

Add another place, you spoke about restricting path to a package path (for security reasons).

[mauritsvanrees]

That is in zcml. There we only accept a path within a package. This is then translated to an absolute directory. This is needed here, because you call runAllImportStepsFromProfile(profile_id=None, path='...') so the code here does not know which package the None profile belongs to.

So in Python code you could call runAllImportStepsFromProfile(profile_id=None, path="/etc") and try to do something clever with /etc/passwd in an import step. But in any import step you can just call open('/etc/passwd') anyway, so this should not raise any further security concerns.

[mauritsvanrees]

I do not like it much:

• special treatment of metadata.xml

This is the same as how we handle archive/tar.

• new tar support without mention in CHANGES.rst
• insufficient documentation for new parameter dependency_strategy

These two are not new. I have only added a bit of missing documentation.

I would prefer alternatively an extended way to identify profiles: not only via registration names but also alternatively e.g. via a path. The different ways could be distinguished via prefixes.

Interesting suggestion. I might try that.

[d-maurer]

Maurits van Rees wrote at 2022-8-30 00:59 -0700:

... This is the same as how we handle archive/tar. > * new tar support without mention in `CHANGES.rst` > * insufficient documentation for new parameter `dependency_strategy` These two are not new. I have only added a bit of missing documentation.

Ok. I did not read the diff correctly. If you have a parameter *path*, you would no longer need *archive* (it could get deprecated). An archive is nothing else than a folder structure in a special form. You could determine the special form via the filename suffix.