change NP_BUILD_DEP for 3.7

[simonjayhawkins]

xref pandas-dev/pandas#37784 (comment)

[simonjayhawkins]

@TomAugspurger @jreback

[jreback]

actually we should merge this anyways. we have a min of 1.16.x on 1.1.5 anyhow.

[simonjayhawkins]

actually we should merge this anyways. we have a min of 1.16.x on 1.1.5 anyhow.

the min for 1.1.x is 1.15.4 https://pandas.pydata.org/pandas-docs/dev/whatsnew/v1.1.0.html#increased-minimum-versions-for-dependencies.

does the NP_BUILD_DEP affect the numpy support of the built wheel, or is NP_BUILD_DEP just for the environment to build the wheel. we test the minimum version in ci on pandas.

also I missed changing the numpy versions for the aarch travis builds, so these are still failing on nightly but should be fixed by #38087 even if not changed here.

[jorisvandenbossche]

does the NP_BUILD_DEP affect the numpy support of the built wheel, or is NP_BUILD_DEP just for the environment to build the wheel. we test the minimum version in ci on pandas.

It does affect the wheel, as we need to build the wheel with the lowest supported numpy version, so a user can install it in an environment with this numpy version (a wheel build with a newer numpy would error in such an environment)

So if this patch is only for 1.2.0, that seems fine, but if it is also used for 1.1.5, it should be reverted I think (I don't know how the branching in this repo works)

[simonjayhawkins]

(I don't know how the branching in this repo works)

everything is built from master (on this branch) so nightly uses pandas master and push commits uses the latest pandas (i.e. 1.1.4)

[jorisvandenbossche]

Some time ago, there was apparently a "maintenance" branch (still exists, but not updated anymore), which might make it easier to test both the bugfix releases as testing the wheels on latest master at the same time.
(not very familiar with this repo, though, so don't know if the above is true in practice)

[jorisvandenbossche]

Because with the current setup, the daily cron job has constantly been testing 1.1.4, instead of the latest master or 1.1.x ?

[simonjayhawkins]

no the cron job uses pandas master.

[simonjayhawkins]

see https://anaconda.org/scipy-wheels-nightly/pandas/files

[simonjayhawkins]

we don't have any nightly builds for 1.1.x and therefore I have been opening a PR to test 1.1.x in advance of release.

generally have been issues with 32 bit since we went for a long period without 32bit testing on our ci. Was hoping that this release would be smoother since pandas-dev/pandas#35898, but 32bit failures are still occurring here. We may need to revisit out setup on pandas ci. see also #113 (comment)

[jorisvandenbossche]

How should I interpret https://travis-ci.com/github/MacPython/pandas-wheels/builds then? That shows that the cron job is failing using the last commit on master, which is using the 1.1.4 tag

[jorisvandenbossche]

Ah, we might be talking passed each other, as you maybe meant the Azure pipeline cron?

[simonjayhawkins]

It was green yesterday after the push, (used pandas 1.1.4) and then went red after the cron job ran (used pandas master)

[jorisvandenbossche]

BTW, since you have been working on this quite a bit, it might be good to document somewhat somewhere the overview of how this repo works / how we use it.

[simonjayhawkins]

How should I interpret https://travis-ci.com/github/MacPython/pandas-wheels/builds then? That shows that the cron job is failing using the last commit on master, which is using the 1.1.4 tag

that link is not showing the latest (cron) job https://github.com/MacPython/pandas-wheels/runs/1461897488

[jorisvandenbossche]

Well, that link is showing the latest cron jobs (you can check the dates), but on travis, which I assume we are not using anymore? (as I said above, we might have been talking about different things, as I was looking at the travis config)

[simonjayhawkins]

So if this patch is only for 1.2.0, that seems fine, but if it is also used for 1.1.5, it should be reverted I think (I don't know how the branching in this repo works)

to be safe, maybe we should revert for now.

[simonjayhawkins]

Well, that link is showing the latest cron jobs (you can check the dates), but on travis, which I assume we are not using anymore? (as I said above, we might have been talking about different things, as I was looking at the travis config)

it is confusing because we have recently started to use travis again but for the arm builds. (that's the reason I overlooked updating it in this PR)

[simonjayhawkins]

I guess the cron job for travis is configured independently (maybe in travis?) and is on a different schedule to the azure builds (cron job configured in code) on https://github.com/MacPython/pandas-wheels where the lastest build is shown as red, but the travis job is still green so that agrees with https://travis-ci.com/github/MacPython/pandas-wheels/builds

[jorisvandenbossche]

I guess the cron job for travis is configured independently (maybe in travis?)

I think you can configure it in travis itself, yes. But so, it running just the latest commit. In Azure, there is some logic to not use the BUILD_COMMIT for the corn jobs:

pandas-wheels/azure/posix.yml

Lines 37 to 38 in fb668ef

	if [ "$BUILD_REASON" == "Schedule" ]; then
	BUILD_COMMIT=$NIGHTLY_BUILD_COMMIT

but on travis, such logic is not present as far as I see. So in the travis yaml, you would need to put eg BUILD_COMMIT=1.1.x after each bug fix release, so keep testing the latest state of the 1.1.x branch

[simonjayhawkins]

looking at the travis config, you could be right about travis not building nightly against pandas master. It looks like the relevant code maybe commented out. will look some more. The arm build was recently added in #99

[simonjayhawkins]

BUILD_COMMIT=1.1.x after each bug fix release, so keep testing the latest state of the 1.1.x branch

probably BUILD_COMMIT=master to be consistent with azure

[simonjayhawkins]

also I missed changing the numpy versions for the aarch travis builds, so these are still failing on nightly but should be fixed by #38087 even if not changed here.

changing NP_BUILD_DEP (and NP_TEST_DEP) for travis e9a011a is causing the tests to fail with master (i.e pandas 1.2) which is concerning.

https://travis-ci.com/github/MacPython/pandas-wheels/jobs/449632801

so maybe need to open an issue for this as well as the nightly wheel build issue.

for now, aarch (and 32bit) wheels are not a blocker for 1.2.0rc0 release.

[simonjayhawkins]

another minor issue is that don't have a clean skip for 3.6 in travis (like in azure)

This may not be relevant once 1.1.5 is released as we will be deleting the 3.6 environments.

[simonjayhawkins]

so maybe need to open an issue for this as well as the nightly wheel build issue.

missed that there is already an open issue for this #102