Looking through some of them they are somewhat similar to the Foundation APIs, but there are a few improvements that I think would make them more compelling for generalized use. I don’t think that it is out of the question to perhaps merge the two concepts and reduce to Foundation as the place to get them.
Things for process execution that might be interesting to consider:
Pipes from one process to another
Safe shorthand’s to a command + arguments
Output collection to Data
More customizable streaming in general (e.g. passing fds other than input output or error)
And I think in my book the biggest part is crafting a way to make the construction of tasks safe by default and not need exceptions or fatal errors (I have played around with this and I really think it can be done with minimal throwing and much better error reporting of failures).
A composeable interface imho would be really nice and i think we could even one-up python.
Argument parsing is another key part that swift does not do and Foundation does not do either but SwiftPM has a good start: again with some refinements I think it could be transmuted into something general purpose (plus there are some interesting open source projects out there)
The one other thing that would be immensely useful is a more integrated and faster regex but that probably should have language support for precompiled regexes and type-checked syntax for them.
Those three areas I think could improve scripting for swift.
Perhaps as a next step we should collect the needs from SwiftPM so that we can provide Process for them instead of duplication of efforts, and file some bugs for enhancement requests.
···
Sent from my iPhone
On Dec 1, 2017, at 4:26 PM, Daniel Dunbar via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 1, 2017, at 6:28 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi Nick,
You might be interested in the new Utility project that the Package
Manager team have published. It has a bunch of Foundation-esque
features including subprocess support, temporary file, progress bars
and more.There's a good blog post about it here:
https://www.hackingwithswift.com/articles/44/apple-s-new-utility-library-will-power-up-command-line-appsI hope it gets more publicity as there's some great functionality
here, which has already been used "for real" by the package manager.Just to be clear, the APIs in that product are developed for SwiftPM’s own use. They are definitely useful to us, but they are also unstable and unsupported… you are welcome to reuse them if you find them helpful, but they are very much designed specifically for SwiftPM and may change unexpectedly. Use at your own risk!
- Daniel
Thanks,
Ian PartridgeOn 30 November 2017 at 08:43, Nick Keets via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote:
In that case I think the discussion is kind of moot, scripts are
fundamentally different than apps, being terse is important and almost
always you want to block.If better scripting support is a non-goal for Foundation then `Process` is
mostly fine as it is. My only wish would be to somehow make it easier to
read and write `Data` to stdin/stdout/stderr.On Tue, Nov 28, 2017 at 11:30 PM, Tony Parker <anthony.parker@apple.com> >>> wrote:
Of course, Foundation API has no way of distinguishing if the caller is
considered a script or not.If the API is a bad idea for other kinds of apps then we simply wouldn’t
add it. So, I think this proposed convenience API needs to consider all of
the varied clients of Foundation.- Tony
On Nov 28, 2017, at 12:24 PM, Brent Royal-Gordon <brent@architechies.com> >>>> wrote:
On Nov 28, 2017, at 8:00 AM, Tony Parker <anthony.parker@apple.com> wrote:
Why does it imply a run loop rather than one of many multithreading
possibilities (dispatch queue, starting one more thread, etc)? And even if
it did use run loops, why is that a problem?The problem is simply that we're discussing using this feature in Swift
*scripts*. Swift scripts don't typically invoke `RunLoop.run()` or
`dispatch_main()`, and without changing the way they generate main()
functions to intrinsically do so (and then schedule main.swift's body on the
main runloop/queue), I don't see a good way for it to do so. So an async API
would be inconvenient to use from a Swift script.--
Brent Royal-Gordon
Architechies_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev--
Ian Partridge
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev