This is not something we want people to depend on.

If there is a need for Packages to have conditional behavior based on conditions, then we should surface that through real features in the package manager (a la Cargo's "features"), not through ad hoc mechanisms crafted by the individual Package.

@mxcl thoughts here? Should we close this out or dup it to an RFE for "features" (or reuse it for that purpose)?

I think it's cool, but only for the root package.

Comment by Bastian Rinsche (JIRA)

I admit that this might take the "the manifest is valid Swift" a little too far, I was trying to use this as a workaround to conditionally exclude a Target that depends on XCTest being installed, but it may be better to wait for real testing support than to introduce this kind of "hack", not sure if there are more reasonable use cases.

I'm OK with the manifest is swift being taken too far, but only for the root package. Since packages you grab from the Internet should have a much more deterministic behavior, or they will easily cause random breakage and in an era where 100 packages is not uncommon, we must be able to predict what is possible and thus be able to manage behavior.

However, the end-user should be able to do whatever they want.

I'm cool with that. Ultimately I think it would be ideal to have proper features to cover the things users want to do, but I agree that for now unrestricting the root package is a convenient way to unblock people.

I am trying to patch this but can't seem to find method to get all environment variables without Foundation's NSProcessInfo or dlsym. Is swiftpm trying to explicitly avoid Foundation or can be used?

Comment by Bastian Rinsche (JIRA)

I think a dependency on Foundation should be avoided, I'd imagine there has to be some way to do that with libc, but I don't know much about interfacing between C and Swift.

Currently Package.swift is deliberately executed in a mostly empty environment.

@aciidb0mb3r Generally speaking, if you want to expose functionality into the manifest, the right way to do so is to add APIs to the PackageDescription module. swiftpm already has all the magic in place to make sure that that runtime library is available.

Introducing an additional dependency on Foundation in that module would be bad though, it should use our existing internal APIs.

We're going to hold on this ticket for the time being, pending something, something.

I agree with Daniel here: enhancing the PackageDescription API to support new ways of declaring intent is great. This will also make it easier to one day provide good IDE integration; the more that is done via custom Swift code, the less visibility the IDE has into the behavior, capabilities, and requirements of a package.

Current environment is now passed to all subprocess by default.