On swiftenv and tools that help you setup your Swift environment

[felix91gr]

I think they have a place. Maybe in this document, or maybe in a dedicated repo about "tools to set-up Swift".

It feels weird adding swiftenv directly here. Not because it's bad (because it's actually magic and rainbows), not at all, but rather because it's not a Swift project per se, but is like a set-up-Swift project. I don't know.

Maybe they should be included in the index, and be mentioned at the top, s.t. a newcomer can know right away where they can go.

[vknabel]

I think adding non-Swift projects for Swift is okay.
vknabel/vscode-swift-development-environment isn't a swift project either (its driver sourcekite is).

Maybe they should be included in the index, and be mentioned at the top, s.t. a newcomer can know right away where they can go.

Agreed, a section for tools for Swift itself would be great.

[felix91gr]

Sorry for the lateness, I've been busy.

Okay so I have a bunch of ideas, lemme know what you think:

Content

I think there are two topics we can cover here:

• Newcomers to Swift: specially for those working on Linux (and maybe in the future, Windows and whatnot), a small guide on how to get Swift toolchains sat up with swiftenv.
• Darwin devs wanting to port libraries: the last Docker-Swift that we shared seems to work really well (right? I can't test it on Linux 😅). Showing how to generate LinuxMain.swift from MacOS would be helpful as well, since most Darwin devs are used to the automatic discovery of tests that SPM provides.
  Pointing out what system frameworks are available on Linux would be really helpful as well. For example, Core Services sadly isn't available, but Dispatch and Foundation (modulo NSUnimplemented() 😅) are.

Displaying

On how to display these topics, I've got at least a couple of different ideas.

Entries in the Index

For example something like this:

---

For newcomers

• swiftenv: Swift version manager. Set up, switch, build and remove your toolchains with ease.

Cross-Platform Testing from MacOS

• docker-swift: test your Swift code on Linux right from MacOS.
• vagrant-swift: set up Linux VMs for testing of your Swift libraries.

---

This is short and easy, but it lacks useful information that we could give to the reader.

Annexes

We put a couple of links at the beginning of the index, to one or two annexes that go after the index, at the bottom. This would leave the index concise and coherent, and would let us give as much information as we'd want in the spaces below.

This is the one I like the most so far.

Wiki

Maybe this information doesn't fit in the index proper. And that could be true. Depending on the point of view, you could say that (a) this information should be part of the index, since they are open source projects from the Swift community, or (b) this information shouldn't be part of the index, since these aren't Swift libraries.

If our answer was the latter, I could make a Wiki and put all of the "off-index" topics right there.

But I don't know. So far, I think this idea could actually help less the newcomers since the UX would be not so intuitive. It would also break the document into 2 different types of document: a structured page (readme) v/s a linked web of small pages (wiki).

Conclusion

I think the best answer is the second, at least to start with. Or I might be missing on a 4th idea that's better.

What do you think?

[vknabel]

Sorry for the late answer.

the last Docker-Swift that we shared seems to work really well

Yes it does!

And I generally agree with you.
At first we could create annexes after the index, but link them at the top (to be recognized by the ready).
If we have enough content we could move it to different .md files within the same repo and just keep the link.