-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Partial migration of Usage.md - topics related to dependencies and C language modules #8709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
cd1bf7d
to
d307ba6
Compare
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice improvement!
Sources/PackageManagerDocs/Documentation.docc/AddingDependencies.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/AddingDependencies.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/AddingDependencies.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
|
||
#### Module Map Versioning | ||
|
||
Version the module maps semantically, using your best judgement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should talk about versioning the package containing the module map rather than the module map itself, which doesn't have any versioning info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole section was a real challenge to transfer forward, as I'm not sure I really understood the original intent from the legacy documentation. I'll take another pass and revising this with your suggestion in mind and see if it works a bit better.
|
||
Follow the conventions of system packagers; for example, the Debian package for `python3` is called `python3`. | ||
In Debian, there is not a single package for python; the system packagers designed it to be installed side-by-side with other versions. | ||
The recommended name for a module map for `python3` on a Debian system is `CPython3`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should refer to the name of the module instead of the name of the module map that defines the module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With your feedback and @rauhul - I rewrote this section to focus on the detail of naming based on system conventions, and highlighted the idea that you may want to reserve a module name separate from the C library module interface for an idiomatic Swift wrapper.
It would be really nice if we could read these docs rendered in context of the entire doc catalog, it would at least help me provide a better review. Is this something we could achieve with a GitHub action? (we'd love to use this swift-embedded-examples too) |
…es.md Co-authored-by: Owen Voorhees <[email protected]>
…ingSystemLibraryDependency.md Co-authored-by: Owen Voorhees <[email protected]>
…ingSystemLibraryDependency.md much better, thank you! Co-authored-by: Owen Voorhees <[email protected]>
@rauhul I agree completely, although I don't currently know a great structure to provide that — even with GH actions. The core difficulty being that viewing the content requires having the content hosted (even if ephemerally) somewhere. I can envision a mechanism that leverages GH pages to do this, but that has some notable challenges in that it doesn't support multiple revisions or parallel work very well, and it's hard to make it clear it's a preview, and not "formal" documentation. (I've done just that for some one-off scenarios, but not as a recurring PR review mechanism) In the meantime, the technique that I'm using (it's far more manual) to review these kinds of PRs involves checking out the PR locally, and using gh pr checkout 8709
swift package --disable-sandbox preview-documentation --target PackageManagerDocs In other open-source projects I've worked on in the past (Kubernetes) the project had explicit CI capabilities that included hosting HTML content through Netlify in an ephemeral way that could be referenced from the PR to view the resulting updates in HTML. I'm familiar enough with DocC to help set that up, but it would involve a lot more coordination (as well as resources and likely funds to be allocated) to enable that kind of functionality. |
@swift-ci please test |
Sources/PackageManagerDocs/Documentation.docc/AddingDependencies.md
Outdated
Show resolved
Hide resolved
Sources/PackageManagerDocs/Documentation.docc/Dependencies/AddingSystemLibraryDependency.md
Outdated
Show resolved
Hide resolved
…es.md Co-authored-by: Owen Voorhees <[email protected]>
@swift-ci please test |
Migrating content from documentation/Usage.md into DocC:
New articles:
And updates to Documentation.md for curating them into the collection as guides.
partial work against #8593