[swift-corelibs-dev] Better integration with UNIX tools

[Daniel Dunbar]

> On Dec 1, 2017, at 6:28 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev at 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-apps
> 
> I 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 Partridge
> 
> On 30 November 2017 at 08:43, Nick Keets via swift-corelibs-dev
> <swift-corelibs-dev at 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 at 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 at architechies.com>
>>> wrote:
>>> 
>>> On Nov 28, 2017, at 8:00 AM, Tony Parker <anthony.parker at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
> 
> 
> 
> -- 
> Ian Partridge
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev