> On Jan 5, 2016, at 4:48 PM, Max Howell <[email protected]> wrote: > >>> Yes, and indeed, this isn’t really acceptable, but I think any changes to >>> how this work would involve a discussion on the swift-build-dev mailing >>> list. Really how targets depend on each other and external dependencies in >>> the Package.swift manifest needs some work in general. >> >> Given that you’ve already recognized the future need for more flexible >> test-module-specific build config, and now there’s also this concern about >> per-test-module dependencies, is it worth considering giving each test >> module its own (possibly implicit) target in Package.swift? That might kill >> several birds with one stone. > > I’m not sure it’s worth it yet. You can’t really do anything with targets in > Package.swift yet (just specify internal inter-module dependencies). I’d > rather wait until the manifest format had some more functionality and had > settled more, rather than slap things in without more understanding about how > the manifest is going to actually be used.
Fair enough. I’d at least make sure that this proposal doesn’t interfere with doing that in the future. (My understanding of the package manager is too shallow to make that assessment myself, so I’ll just leave the thought sitting there….) >>> You should be running and checking the tests of your dependencies somewhat >>> regularly. >>> >>> But when developing your own software, this would be a waste of engineering >>> time. >> >> Indeed, clearly that should not be the default. In general, assuming >> unnecessary building to be “almost free” is a mistake. >> … >> However, having the option to run dependency tests seems very nice. > > I agree and I wish we could force all tests to be run. But this is just > idealism. Practically all of us would just start building with the “don’t do > that flag”. > > I think at the least when we have a “publish” command we will run all the > tests. As well as lint. In day to day development we cannot expect developers > to wait, but we have a duty to ensure the packaging ecosystem we help create > is as high quality as possible. Yes, anything that slows or complicates the dev cycle will send everyone straight to “torches and pitchforks” mode, and will be the target of hacks and workarounds galore. The normal build cycle needs to be as lean as possible. Running dependency tests by default for any sort of “publish” command seems right. Now lint … lint I’m not sure about. It’s problematic as soon as you try to establish a standard, as we’ve already established on this list in the “mandatory self” discussion. The truth is that I don’t care about a third party lib’s weird formatting decisions nearly as much as I care about its tests passing. Cheers, Paul _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
