Remove Foo modules

[JJ]

There are 3 of them which show up when searching for test. They should probably be removed.

[stmuk]

They are there specifically to test for the case of modules having the same name (which is allowed).

[JJ]

Um, but that's already tested. They don't need to stay there, right?

[stmuk]

Looking at this another way does anyone but the original author have the right to delete a module from the ecosystem anyway?

I can see some genuine reasons for doing this (eg. removing malicious code) but just "cleaning up" because we think they aren't needed doesn't seem valid to me.

If you really want to do this I suggest you contact the original module owners/committers and only delete if they say its ok.

[JJ]

2018-04-12 9:31 GMT+02:00 Steve Mynott <notifications@github.com>:

Looking at this another way does anyone but the original author have the right to delete a module from the ecosystem anyway?

I was expecting the original author read this :-)

I can see some genuine reasons for doing this (eg. removing malicious code) but just "cleaning up" because we think they aren't needed doesn't seem valid to me. If you really want to do this I suggest you contact the original module owners/committers and only delete if they say its ok.

That's exactly what I expected from this issue. I can do it much more explicitly if needed. That's why I've opened the issue instead of removing them directly.

[stmuk]

@JJ Aren't the original authors more likely to see this under the issues for the original modules themselves rather than here?

[JJ]

@stmuk right.

[JJ]

They were not added as part of an issue, they were directly added here by @FROGGS. I guess that would mean that they can be safely removed the same way, but at any rate, I guess he'll be aware of this issue now :-)

[stmuk]

@JJ There is another Foo module added by @ugexe

[JJ]

Haven't been able to find it, but I guess he'll be notified by your mention.

[ugexe]

They aren’t testing the ability of someone to upload such a module — they are for toolchain utilities such as zef to test searching and choosing between similar options.

[JJ]

Nothing prevents them from using a real module. Finding them when looking for modules is going to be confusing.

[ugexe]

What real modules currently flex differences in auth only and also version only? And are they written in a way that they act as a good test module (won’t fail it’s tests we don’t care about, won’t fail it’s build, a dependency is added, etc)?

Additionally one cannot say this is confusing for everyone — you do not know if someone now (or in the future) will be writing their own CompUnit::Repository and want to test such a thing.

The ecosystem is not a curated list of modules — it’s not intended to be consumed directly by a human.

[AlexDaniel]

I'm totally fine with keeping these modules there. Maybe it would be nice if they had a description explaining why they exist, something similar to what @ugexe++ provided above.

[ugexe]

https://github.com/ugexe/Perl6-Foo <- @JJ fwiw this is the version I put up, which I imagine you would not have had this issue with. But I don't think the perl6 modules web service handles this as expected, so you only see the ones with little description.

[JJ]

I don't think I saw that one, actually. Just the two of them mentioned above.

[benjif]

I agree with JJ on the removal of the three Foo modules. They all appear on https://modules.perl6.org/, serving as both a confusion and spam.

[AlexDaniel]

There are more than three Foo modules. Check it out again. Most of them are authored by me. While I'm kinda OK with delisting them visually from modules.perl6.org, they're actually there to find actual bugs. For example, check out the module named “../Foo”. It is there to demonstrate that modules.perl6.org does not escape things correctly.

[JJ]

@AlexDaniel wouldn't it be better to just create a clone of this list, instead of using the real one?

[AlexDaniel]

What do you mean? Why?

[JJ]

If the main intention of having test modules in the production ecosystem is to test some features, those features could possible be tested in a test ecosystem, and not left in the production ecosystem. At the end of the day, it's a string in a program, you can probably change it from https://github.com/Raku/ecosystem to https://github.com/Whoever/ecosystem or even https://github.com/Raku/mock-ecosystem.

[AlexDaniel]

To be honest, I don't care anymore. Sure, go ahead, hide modules that deliberately expose bugs in tooling.

[AlexDaniel]

Also, FYI, some of the Foo modules are used for testing Blin. Feel free to take over Blin and maintain it, given that it's just “a string in a program”.

[Altai-man]

@JJ is there actual harm done by those modules?

If you type in "Test" and get them first, it is because the search results ordering is bogus (it should first show exact matches by name and then by description). Improving sorting would also make results to all the queries better in general.
Removing the help modules sweeps the real issue (bogus search ordering) under the carpet, and mild harmful at best (removing regression checks we want to have).

[JJ]

@Altai-man we probably need to decide first what META.list is for. If we think that's it's a list of modules that are searchable by zef and that people can download and install, well, if they can't be downloaded and installed, they don't belong there. I could turn around the question. Is there any function they do that can't be done in any other way? Or that they have done already and is no longer needed? Or that can be done by adding them temporarily and then removing them?

[ugexe]

The ecosystem doesn't know the health of a module. Just because YOU can't get it to install on whatever system YOU have doesn't mean some exotic system can't install it successfully. I don't know about you but having a separate ecosystem for such exotic modules sounds rather silly.

if they can't be downloaded

What modules can't be downloaded? And if such things exists couldn't they be downloaded with a zef plugin? In other words -- the p6c ecosystem isn't omnipotent and can't possibly know what is downloadable or not for a given user.

Is there any function they do that can't be done in any other way?

Is there any function the problem you are complaining about can be done in any other way?

[JJ]

I'm getting kind of lost here. First, let us see what I'm talking about.

Let's look at the original post date, which was April 2018. These three were the only "Foo"s back them. Three modules, all of them called Foo. All of them saying "Test for installation of...". The point of this issue was: did that test pass? Or fail? Is it continuing?
I couldn't possibly know about AlexDaniel's Foo modules, which somehow along the way got blended in this discussion. I might or might not have an issue with them, but if I (or someone) does, it's definitely not this issue.
As far as I can tell, installing distributions with different auths has many other examples in the ecosystem. Also, that test happened 3 years ago. So can we at least agree that seeing them showing up as search results serves no purpose?

[AlexDaniel]

it's definitely not this issue

I think it is. All these modules are not meant to be used by users. They are there so that you can test tools. While Foo, Foo and Foo modules test that installation of same named dists works, Foo::Dependencies::B-on-A and Foo::Dependencies::A-on-B are meant to test what happens when you try to install modules with cyclic dependencies, etc.

Talking about all these modules, “the test” passed for some tools, failed for others, but essentially it is still continuing.

[AlexDaniel]

To make it a bit cleaner, you can rename all three to “Foo::SameName”, unless there are tests somewhere that have the name hardcoded (in which case either rename it there too, or just drop the idea).

[JJ]

So, let me see if I understand that correctly (and please allow me to stick to the original post intention): The three Foo modules with different auths are still being used to test some tool?
In that case, let me again turn around what you're proposing about renaming them. If they are not being used continuously, it's still the same problem. If they are and we have a bunch of modules that are using the self same production infrastructure as the rest of the modules, could we at least agree on some naming convention so that we could work around them? If that ends up being Foo::Something, let that be. But if, as you say, "they are not meant to be used by users" there should be some easy way to mark them so that they don't show up in searches, or in modules.raku.org.

[Altai-man]

The three Foo modules with different auths are still being used to test some tool?

Yes.

there should be some easy way to mark them so that they don't show up in searches, or in modules.raku.org

Improving the search sorting suggested above?

[JJ]

At any rate, the OP is about removing these modules. It's quite clear now they shouldn't. So I guess the best now is to close this issue.