@jni, so it didn't work right, not with the min requirements. I'll just add a "'string" to the front of the path to cast it as one.

Codecov Report

Merging #3324 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #3324      +/-   ##
=========================================
+ Coverage   86.77%   86.8%   +0.02%     
=========================================
  Files         339     339              
  Lines       27380   27386       +6     
=========================================
+ Hits        23760   23773      +13     
+ Misses       3620    3613       -7

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 02c6eb9...f8dd851. Read the comment docs.

Oooooh, older NumPy has the same problem I mentioned above. Of course. =)

I feel like this whole string -> path is a going to be a repeat of bytearray -> string
But hopefully it won't create a new version of python :D

There is also some data in skimage/color/tests/data/. Let me know if you would like to handle those files in this PR or not.

@soupault I moved that data, but it was a really small file. The data in restoration was quite large.

@hmaarrfk I was mentioning the ones from color/tests/data, not color/tests - https://github.com/scikit-image/scikit-image/tree/master/skimage/color/tests/data 🙂 .

🎠

@hmaarrfk Hmm, sorry, I've just noticed that those latter files are quite small, and we don't introduce too much sense moving them... Although, the consistency is a good thing, in any case. I think, I still prefer the PR in its current state. Thanks!
@jni are you OK with the changes?

Thats ok. Depending on @jni's comments, I can revert them quite easily. Undoing the revert would be harder ;)

I agree with @soupault, I like the consistency of having all data files under one tree. However I wouldn't mind a third @scikit-image/core chiming in.

It's not a bad thing to combine.

I think it is interesting maintain the distinction between the data that can be used for a broad range of things (what the current data is) and the data used for specific tests (that the common users will never care about).

In the taste of keeping things separate a little, wouldn't be interesting to do not put theses data in tests/ (that I associate with the tests for data/) and move them in a directory named like "for_unittests" (or anything better).

For my point number 1, yes :) That point was just to underline the importance to keep things tidy. About my point number 2, I would say no. Usually, skimage/SUBMODULE/tests contains the tests of SUBMODULE, not the data for another part. Here, skimade/data/tests contains the tests for our front-end data. Therefore, I suggested to put the files somewhere else, like skimage/data/for_unittests (but the name is not excellent...). Is that clear?

@hmaarrfk are you considering moving the files to another directory inside data (like suggested by @sciunto ?)? [I'm going through the merge + 1 PRs and had the impression that this one was ready, but the suggestion of @sciunto seems like an improvement]

lets see what happens with the cis.

it works :)

Can we just leave this as is for a while? Maybe we can think of a better way in a bit, I'm fine with having this one wait until we are ready to pull the trigger on a real solution for splitting off the data package.

I can touchup this PR if it needs to in th near future.

@hmaarrfk Should we close this PR? Turn it to an issue?

I think it can just be closed. Pooch dealt with this