Implicit dependency on Test::Coverage for development

[2colours]

File-Find/xt/coverage.rakutest

Line 1 in 605690d

use Test::Coverage;

but https://github.com/raku-community-modules/File-Find/blob/main/META6.json doesn't specify this dependency anywhere. It needs to be installed manually or else mi6 test will fail.

Maybe all we need is an entry for test-depends, or does that get installed for all users?

[lizmat]

In my book it is not a test dependency, as it is only needed when the developer tests (in the "xt" directory) are being run. When the tests are being run in CI, they are not needed.

Perhaps we need an entry "developer-depends": please check out Raku/problem-solving#491

[2colours]

In this case, I would prefer to keep the issue open but there is no reason to have you assigned. After all, there is an issue that affects this distribution, namely that the developer has the most streamlined installation process via plain trial-and-error.

I hoped there would be a straightforward solution to have dependencies like this installed, perhaps with a certain zef flag, that you would know by heart. If there is no easy and standardized solution, then this is more of a global issue, still affecting this distribution in particular, so it shouldn't masquerade as something resolved.

[lizmat]

Note that all community modules that were recently updated by me, would have the same issue.

And I don't think it's a good idea to be burning CI CPU cycles to install Test::Coverage for testing, when it is not needed there.

So I think maybe this should just be a rite of passage for community module maintainers.

In other words, there's no reason to keep the issue open here.

[2colours]

So I think maybe this should just be a rite of passage for community module maintainers.

I don't think there is any particular reason why we should settle for development dependencies lacking any comprehensive meta information and being installed manually. Without having some comprehensive study down in my pocket, Composer has "dev requirements" for PHP package management and npm has "dev dependencies" for Javascript package management. It also seems to me that modern Python project can have dependency groups for this kind of purpose.

Note that all community modules that were recently updated by me, would have the same issue.

This is an odd argument; I wonder if this phenomenon has a name. To me, this just means the situation is actually quite severe. If your point is that there is no reason to keep an issue here of all places, maybe you are right; this should probably be escalated, with some examples listed (possibly including this repo). This issue could be even transferred to some preferred place. It is still as much an issue as it was before knowing how much it is already affecting the ecosystem overall, therefore I think closing it would give the wrong idea. It almost contradicts raising a general issue: if there is a general issue, why would we want to give the outlook that a specific example was resolved or revoked?

(By the way, if "test dependencies" do what the name suggests, this is not a very useful thing for Raku since executing the tests is the default behavior, in other words, tests are basically considered a part of the shipped product.)

[lizmat]

So I think maybe this should just be a rite of passage for community module maintainers.

Until we can specify this in the META6.json, obviously. Duh.

Note that all community modules that were recently updated by me, would have the same issue.

That is not an argument, it is a statement of fact.

If your point is that there is no reason to keep an issue here of all places, maybe you are right; this should probably be escalated,

That's why I mentioned Raku/problem-solving#491 : "Perhaps we need an entry "developer-depends"

By the way, if "test dependencies" do what the name suggests, this is not a very useful thing for Raku since executing the tests is the default behavior, in other words, tests are basically considered a part of the shipped product

Test dependencies are staged (if they are not installed already) so that they are accessible for the tests, but are not installed when a module is installed. So it may be part of the shipped product, it is not part of the final installation.

[2colours]

Just for the record: I do feel an attitude in your sentences yet again. I don't want to escalate but I do have to point it out at the very least.

That is not an argument, it is a statement of fact.

There is no contradiction between the two. So you are saying there was no particular reason you mentioned this fact? Well, alright.

That's why I mentioned Raku/problem-solving#491 : "Perhaps we need an entry "developer-depends"

I mean it's alright; I for one don't find it emphatic enough. It's mentioned as "auth stage" as much as I can tell. You mentioned it and sjn recited it, nobody else has reflected on it. To me these big collector issues seem to pend for eternity and not distinguish or prioritize enough. They don't generate the kind of interest or technical discussion around specific topics that would be necessary.

Test dependencies are staged (if they are not installed already) so that they are accessible for the tests, but are not installed when a module is installed.

Again, this might be a statement of fact but not sure what follows from it. "Test dependencies" need to be made available and running at the user during installation. If it makes any difference at all to the user whether they are kept after the testing or not, I'm not sure if authoring dependencies should be permanently installed or just invoked under certain circumstances. Maybe it's really better to install them for good but when or under what conditions remains a question.

[lizmat]

Maybe it's really better to install them for good but when or under what conditions remains a question.

If the developer wanted them to be installed permanently, then they would be in the "depends" section.

If the user wants them installed permanently, then they can manually. Or maybe we should have a --install-test-deps option in zef that would automate this.

[2colours]

So to summarize it, just so that we talk about the same thing for sure:

• if the developer wanted the end user to have a distribution installed, they would have put it in the "depends"
• if the end user wants for themselves to have a distribution, they can just install it
• if the user finds it preferrable to install test dependencies for good, there could be an option in zef for that - I think it might be nice but definitely not very high priority
• if the developer wants other developers to have a distribution, well, right now they don't really have anything, which is the issue that I'd like to preserve some way, even if it isn't specific to this repo. A separate issue or really just some attention to it would be nice, I don't insist on this one issue being here, I just think it's better than nothing.