Create REQUIRE and appveyor.yml during Pkg.generate

[tkelman]

also forward-port a few package doc commits

[tkelman]

@StefanKarpinski any thoughts?

[yuyichao]

Is AppVeyor working out-of-the-box for packages now? (I thought you mentioned some problem during JuliaCon what I remembered is probably about binary dependency so NVM)

[tkelman]

Did I? Where? https://github.com/tkelman/JuliaCon2015/blob/master/KelmanJuliaCon2015.pdf

If a package doesn't have binary dependencies, or if the binary dependencies have been properly set up for Windows too, then this appveyor template should just work.

[tkelman]

Win64 tests for packages can and do occasionally hit #7942, which requires just restarting builds occasionally like it does here. That's a Julia bug, not an AppVeyor problem though.

If we had been chatting around the beginning of JuliaCon, there was a bit of a mess at the time involving the toolchain used for Windows builds and libstdc++ ABI compatibility with WinRPM packages, but that's all sorted now (was the reason I tagged 0.3.10 at that time).

[wildart]

I like an idea of REQUIRE file on package generation, but not service specific files. Services tend to change API, thus we need constantly update Base code. I would prefer some information displayed (possibly on Julia doc site) after package creation which points on various helpful for developers services and how-to for their setup, rather then silently create a bunch of suspicious files which are not related to Julia programming and package development.

[tkelman]

The problem with docs is people don't read them. I agree that the clutter is a little bit annoying, but if we make things as easy as possible for people who have no idea what continuous integration is to just click one button to turn things on, I think it'll help improve the overall quality of the entire package ecosystem.

We can maybe ask for @FeodorFitsner's opinion on how likely anything on the AppVeyor side could possibly break this in the future.

[wildart]

Developers still need to create an account for these services and do minimal configuration in order to get them working. Many people start developing packages without any thought about unit testing, CI and code coverage. I think devs need just a basic package structure to start working. Later when a developer decides to publish work to the Julia package repository, all development related services come in handy. IMHO, better documentation on publishing a package to Julia repository (including various dev services setups) and careful supervision of a first package publishing from the community is a better option, then silently inserting files into package.

[wildart]

BTW, some packages can target only one platform, because of binary dependencies or dev inability of developing for other platform.

[tkelman]

That's fine, actually using Travis and AppVeyor is optional, but strongly encouraged. Yes, we should probably start holding METADATA to a higher standard, ref JuliaLang/METADATA.jl#2800, but that requires work and automation of things that are currently checked by hand and somewhat inconsistently. We can probably move some of these optional pieces to non-default steps down the road, but for now my feeling is this would do a lot of good and very little harm.

[tkelman]

As far as giving preferential treatment to specific services goes, my impression is that the community has not been particularly shy about picking the services that work best and going with them. Github over Bitbucket, homebrew over macports, Travis over Drone/Circle/Shippable, and other similar cases. We can try to make things flexible where other services could be used instead (bitbucket should work fine with Pkg.clone for example), but generally I think people have been happy to pick one option and use that in the vast majority of cases, leaving the work of supporting other options to whoever feels really strongly and wants to do the work.

[davidanthoff]

+1 on this PR, thanks!

[tkelman]

Do we just need @StefanKarpinski to make an executive decision one way or another on this? I don't feel like adding a 30-line file by default is all that harmful, but I can take out the appveyor.yml generation if there's more disagreement about it.

[StefanKarpinski]

Do it.

[tkelman]

That's slightly ambiguous, but I'll interpret it as "hit merge." Thanks.