More layering changes...


(Daniel Dunbar) #1

Hi all,

As a heads up, I'm planning on doing some more work on the internal module layering of SwiftPM. The intent is to define a clear conceptual purpose to each of the modules in the layering, so that it is more obvious exactly what the dependencies between modules are, and where new code should go. My current plan is this:

libc, POSIX, Basic, Utility
- I already sent a mail on the purpose of these, but roughly speaking this is the general "Support" layer.

PackageDescription:
- This is a special snowflake, it defines the APIs used in the `Package.swift` files and so needs to stay as decoupled as possible

PackageModel (renamed from PackageType):
- This defines the basic model objects for Packages. The rename is to try and convey the intent more clearly. This module is intended to define "pure" model objects.

PackageLoader
- This is a new module combining what is currently `Transmute`, the conceptual purpose of which is to take an input Package, apply the convention system and transformations, and output a completed Package (in terms of the same model objects exposed from `PackageModel`).

PackageGraph
- This is a new module which is intended to export the organized group of packages which together constitute what is needed for the higher level operations. This module will probably export derived data structures on top of the basic model objects, for example target-level dependencies at this point should be fully resolved (and efficiently queryable) and the semantics of the targets should be well defined. This is so that higher level libraries like `Build` or `Xcodeproj` can operate on a model object which describes as fully as possible the semantics of the project.

Build, Xcodeproj
- These are the "build" implementations we have today.

Tools
- This is a new high-level module to encapsulate the tooling layers (option parsing, usage, command line diagnostics). We can avoid this if we decide on an implementation of `swift-build` and `swift-test` that just indirects to `swift-package`, in which case this would just be the `swift-package` module for now.

swift-build, swift-test, swift-package
- These will be thin executables on top of Tools and ultimately everything else, which we will probably move to enclosing in a libSwiftPM DSO, as part of implementing the `swift package` rename proposal.

I'm still sorting out where exactly the (package-level) dependency graph resolution and SCM interactions will all live in this organization, one possibility is that much of that logic lives in its own module, another possibility is that it is built out of much more basic infrastructure and then the high-level plumbing lives at the PackageGraph level.

Feedback welcome!
- Daniel


(Anders Bertelrud) #2

Just to clarify what we mean by “pure” here — there should be no conventions or other magic applied at this level, and no intermixed resolution policies etc. That’s added by higher levels. Also, at this level there are no connection between packages — that happens in PackageGraph.

Anders

···

On 2016-05-17, at 17.26, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

PackageModel (renamed from PackageType):
- This defines the basic model objects for Packages. The rename is to try and convey the intent more clearly. This module is intended to define "pure" model objects.


(Daniel Dunbar) #3

The layering refactoring is now done, PRs are safe from gratuitous conflicting once again!

I have added a couple README files, e.g.:
  https://github.com/apple/swift-package-manager/blob/master/Sources/PackageModel/README.md
to documentation the layering intent for each module, and our own `Package.swift` has an overview of the structure:
  https://github.com/apple/swift-package-manager/blob/master/Package.swift

PackageModel (renamed from PackageType):
- This defines the basic model objects for Packages. The rename is to try and convey the intent more clearly. This module is intended to define "pure" model objects.

Just to clarify what we mean by “pure” here — there should be no conventions or other magic applied at this level, and no intermixed resolution policies etc. That’s added by higher levels. Also, at this level there are no connection between packages — that happens in PackageGraph.

Indeed. I stole your pure terminology for the README above.

- Daniel

···

On May 18, 2016, at 9:01 AM, Anders Bertelrud <anders@apple.com> wrote:
On 2016-05-17, at 17.26, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

Anders


(Ankit Agarwal) #4

Awesome!

···

On Friday 20 May 2016, Daniel Dunbar via swift-build-dev < swift-build-dev@swift.org> wrote:

The layering refactoring is now done, PRs are safe from gratuitous
conflicting once again!

I have added a couple README files, e.g.:

https://github.com/apple/swift-package-manager/blob/master/Sources/PackageModel/README.md
to documentation the layering intent for each module, and our own
`Package.swift` has an overview of the structure:
  https://github.com/apple/swift-package-manager/blob/master/Package.swift

> On May 18, 2016, at 9:01 AM, Anders Bertelrud <anders@apple.com > <javascript:;>> wrote:
>
> On 2016-05-17, at 17.26, Daniel Dunbar via swift-build-dev < > swift-build-dev@swift.org <javascript:;>> wrote:
>
>> PackageModel (renamed from PackageType):
>> - This defines the basic model objects for Packages. The rename is to
try and convey the intent more clearly. This module is intended to define
"pure" model objects.
>
> Just to clarify what we mean by “pure” here — there should be no
conventions or other magic applied at this level, and no intermixed
resolution policies etc. That’s added by higher levels. Also, at this
level there are no connection between packages — that happens in
PackageGraph.

Indeed. I stole your pure terminology for the README above.

- Daniel

>
> Anders
>

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-build-dev

--
Ankit