We should consider the namespace implications of these names.

Comment by Kostiantyn Koval (JIRA)

How about the "metadata" tag? Now SPM support it, should it be also included?
#64

public let version: (Int, Int, Int, String)

Good point. Probably `String?`. Matching the `Version` initializer.

Worth considering: adding the SHA too.

what should be the name of the generated swift file? <packagename>.swift can clash

some of the name spacing implications :

if a global/local is defined with name `url` or `version` it'll take precedence
if no global/local is defined and only one module is imported then `url` or `version` will default to that module
if two modules are imported then `url` or `version` will not work and <modulename>.url can be used.

Comment by Kostiantyn Koval (JIRA)

To generate this file a package must be a git repo. How about local packages?
Does this file should be generated for a root package too, or only for dependencies packages that we fetch?

For the root package we can generate it if there is a Git repo there, otherwise, not.

Comment by Kostiantyn Koval (JIRA)

I've started initial work on it [PR-122 | #122]

Can you clarify the intent of this work?

Some projects might not want dependency version information embedded inside them. And using the embedded version information for runtime compatibility checks may not be something we really want to encourage (vs. a more explicit mechanism, e.g., real language support for it).

For example:

A web server product provides diagnostics when it fails to connect to its port, part of this diagnostics is a dump of the version information for the socket library it uses.

What is left here?

Comment by Kostiantyn Koval (JIRA)

I think first would be nice to find a use-case and tune this functionality for it.

It is not yet possible to use the version constants, they are generated, but not importable.

We need to revisit this and consider the generated version symbols to be part of the SwiftPM API (since we won't easily be able to change them in the future without breaking anything).

Comment by Eric Blachère (JIRA)

Sorry for reviving this old topic, but is there any plan for this to happen ? Or is there currently already a way to access the version of an SPM module from the code ? We use to access the info.plist but it's not here anymore 😉 Thanks !