hi all,
after taking all the feedback on naming into account, we have tentatively chosen the new name of Environment-Dependent Shared Libraries, which we think better-communicates the scope and intended purpose of this feature.
i’ve also updated the pitch to use the updated terminology.
hi everyone! i’ve got two more updates for EDSL fans:
first, i added tests for EDSLs to the swift-package-manager repo, which now builds a rudimentary EDSL inside the Swift CI runners on macOS and Linux, and verifies that clients can link against them. there are also new unit tests for the small number of extensions we added to the .artifactbundle format.
secondly, there is now an official tutorial for how to use EDSLs, which is available here.
Hi folks.
The Platform Steering Group is looking to run a review of this proposal, but having looked over it we did have a few comments that we feel need addressing beforehand, namely:
Please can we drop the reference to "a small set of paying clients" under "Organization-Defined Platforms (ODPs)".
While it's conceivable that someone might be doing e.g. consulting work for an organization and wish to use EDSLs in that situation, we don't want to give the impression that distributing things in this manner is a good idea in a more general context.
It might be better, rather than saying "strictly for internal consumption within an organization", to explain that they are for use in a known environment, typically one maintained by a single individual or organization, rather than for widespread distribution.
Folks here may also be aware that maintaining such an environment is not necessarily a trivial matter, and while we agree that this proposal meets a real need, we don't want people to rush into using EDSLs only to discover that that they have unexpected difficulties with maintenance and deployment. Perhaps there should be an explicit warning about this too?
We have a slight concern that the proposal is a little jargon-heavy; in particular the notion of an ODP seems to be unnecessary given that it has no specific identifier and the artifactbundle does not, therefore, mention which ODP it is for. It's also slightly confusing in that the proposal then states
To keep things simple, we identify ODPs by the URL of the Artifact Bundle that contains the EDSL.
which seems on the face of it to imply a 1:1 relationship between ODPs and artifactbundle URLs, which makes it doubly odd that we're defining the notion of an ODP in the first place. We realise that the sentence was probably intended to suggest that the prefix of the URL might be used to identify the ODP on which the bundle was usable, but even that presents obvious difficulties (e.g. what about ODPs that are based on an upstream ODP?) and is really no more than a suggestion.
We think it would be sufficient to state that the proposal does not specify any means to identify the environment in which a particular EDSL will execute, that the set of environments supported by an EDSL is explicitly a matter for the EDSL and environment maintainers, and that Swift tooling will not, on its own, prevent you from installing an EDSL in an incompatible environment.
Kind regards,
Alastair Houghton
Platform Steering Group
Has anyone mentioned yet that EDSL is a term of art for Embedded Domain Specific Languages and thus it's very confusing to see it mean something completely different and unrelated? Especially as SwiftPM has its own EDSL declared in PackageDescription and used in Package.swift.
Nope… Environment-Constrained instead…?
As far as I understand, at this point the pitch is essentially a follow-up to SE-0482 Binary Static Library Dependencies, but for dynamic library dependencies. Why not call it that way to avoid any confusion?
As for the proposed changes, SE-0482 introduces "type": "staticLibrary", thus it makes more sense for this pitch to be more specific and to use "type": "dynamicLibrary" or "sharedLibrary" instead of "library".
Lastly, SE-0482 introduces an auditing tool, as in the absence of ABI stability it is necessary to ensure that ABI mismatches are prevented. Shared dynamically-linked libraries introduce many more pitfalls of that nature. It would be great to see this pitch improving the auditing tool to enforce ABI compatibility for dynamic libraries and to improve upon the status quo of binary library distribution, or at the very least not to regress it.
I do see "if it builds then it likely works" praise for statically typed languages in general and Swift specifically. It would be very unfortunate to see that expectation subverted by possible introduction of packages with hard to diagnose and to debug runtime errors due to ABI mismatch or due to duplicate symbols loaded dynamically. It is pretty much package manager's and/or build system's responsibility to track the linkage graph and available ABI versions, and to validate the linkage graph preventing issues at build time.
hi everyone,
thank you all for the valuable feedback, we’ve gone back and revised the proposal text, the implementation, and the example projects to incorporate your suggestions.
the new proposal text can be found on GitHub.
key points:
info.json schema from "type": "library" to "type": "dynamicLibrary"thank you for your time reviewing this proposal!