Delist packages that depend on DI implementations

[atrauzzi]

Given that this project aims to collate the best of the best packages, it would be wise to ensure any projects that do get listed do not impose container requirements on consumers.

Instead, the community should be encouraged to produce injection friendly libraries. This repository is likely to get a lot of attention and it would be unfortunate if the presence of a library that imposes a container prevents one that does not from being made.

An alternative might be to group container ecosystem specific packages within separate .md files. That's way people can shop and gauge the health of each container ecosystem.

[pleb]

@atrauzzi project dependencies can be a pain and DI dependency is one of many. Off the top of my head, I can think of logging, database and PCL. But I really can't see this pain-point going away anytime soon. When looking for a library, a developer must take into account these dependencies in addition any other selection criteria they may have. My vote would be for no change to how the list is run.

However, I've tagged this for discussion and the community and other mods are welcome to comment. Please note, though, if there's a lack or interest/activity I will close this issue.

[atrauzzi]

It's not so much about making the pain point go away immediately as it is encouraging .net package authors to begin taking on a better approach. Have to start somewhere and this repo intends to be a crossroads.

Maybe a table-like layout is in order with columns for the TFM, logging and container systems and then icons for the various options that fill those as well as icons indicating agnostic/multi support?

[zihotki]

Delisting them because of some limitations is not a good idea, I think. And creating a table instead of what we have now also seems not ideal because it'll be too verbose for the purpose of the list which is, as it seems to me, to simplify discovery of good tools and libraries, we don't compare the libraries here. And for discovery I prefer to have a short paraghraph or two with description and limitations. Also keep in mind that it'll be harder to support the list. DI, logging framework can be easily changed most of the time. And of course nobody limits you from using two DI containers or logging frameworks side by side, there are a plenty of ways to integrate them. Of course that's not ideal but if you desperately need the library and to complete the task - that's good enough.

[atrauzzi]

DI, logging framework can be easily changed most of the time.

That's just not true, and even if it was, then the maintainer would see no issue in removing the container as a dependency. If the project won't build without the container it's flagged as a dependency, something is wrong. Reality is, when people bundle a DI framework, the coupling ends up being high, it just hasn't been thought out enough.

Organically, consumers will steer around any package that makes such an imposition, it's probably more work to police bad packages than it is to simply hold the ones that do get listed to some kind of standard. Not only because of the technical overhead, but again, because the design is probably quite poor. In some cases it might also be because some DI systems can imply vendors people have specifically chosen to steer away from.

there are a plenty of ways to integrate them

Sorry, no way. This is just inviting a nightmare to projects that actually take this advice. Is this "awesome .net packages", or "as many .net packages as we can indiscriminately jam onto a page"? Packages that bundle DI are quite objectively not awesome.

[zihotki]

@atrauzzi There are only a few cases when maintainer sticks to specific DI or logging framework because of some unique feature, performance reasons or lack of time/experience. And this is very minor issue most of the time and easily solvable in many ways in a few hours. And you can always raise an issue and send a pull request to the library or fork it. If library saves you several man-months spending a few hours for that or a few hours for dirty temporary-ish hack will still lead to huge gain at the end. On the other hand if the library saves only a few man-days which means it's very small, it doesn't belong to the list. I personally tend to reject such pull requests.

As for the code quality, smells, etc. in some abstract project please don't add that to the discussion, that's too abstract and we can spend weeks discussing that without any conclusion. There are no ideal projects, in my native language we have a saying - 'the best' is an enemy of 'good'. If a project solves some moderate problem, has unit tests and documentation, and proven by time - it can be counted as awesome no matter what logging library or DI it's using, it's good enough to be included in the awesome list. And the key is - solves. If you dislike some decisions made there - create an issue for the project and discuss it with the author instead of trying to force or limit anyone, let's be a community but not a police.

[atrauzzi]

It totally merits being added considering what you just told me is to take it up with the authors. Beyond that, it's a complete waste of my time to browse a list and have to selectively filter out all that make the mistake of taking a dependency on a DI framework. To be clear, the way you're addressing this is as if I'm turning this into a "religious" discussion about which container. The point is that it shouldn't be any at all.

Container influence in general needs to be mitigated so that the list can apply to the largest audience rather than be riddled with disappointments. It will also help the community to spread the reality that bundling DI is bad.

[pleb]

It's a list of awesome .net things. All listed items will have different use cases, and many will not be suitable for a particular use. However, in my opinion, it gives a short list that a developer can use that MAY speed up the time to find a .net thing.

Not all awesome .net things will be listed; such is life. Not everyone will agree; such is life.

At the end of the day, if a developer is looking for a .net thing, they must do their background work to ensure that the .net thing will work for them; work for their use case.

If a .net thing has any dependency, then part of the decision-making process for using the .net thing should be "do I too want this as a dependency?" If the answer is no, move on, it's not what you're looking for.

[medokin]

Why not just add a hint that a specific DI is needed?

[atrauzzi]

Packages - which are not base projects/skeletons/scaffolds - that depend on DI containers are poorly abstracted. That in itself should make a package demonstrably not-awesome.

A hint would be a compromise to the main point which is that it's a massive pain to go package by package in a resource that's supposed to collate the most well conceptualized and designed of them.

I don't think the maintainers understand this.

[pleb]

@atrauzzi this is a hard one.

I'd favour a tag to state the lock-in. For example [Lock-in Nlog, Json.net]

Thoughts?

[atrauzzi]

If a that approach is taken, it has to be filterable/sortable. But please I hope this thought isn't seen as an indication that I agree they should be listed in the first place.

These packages have to be awesome. Bundled DI literally goes against the premise of DI which is decoupling. Libraries that don't understand this are cause for concern, which is definitely not awesome.

The optics of listing packages that are unsuitable to the majority of use cases (as a package that uses a DI container is always doomed to be unsuitable to the majority) is way more damaging to the index. It means some people may see it and assume the community has done a good job already, when really the complete opposite is more than likely true.

There are so many reasons why awesome has to mean something here and be effectual. Otherwise this repository is just a package index.

Add value? I'm not sure what other terms I can use here to emphasize what I'm getting at, but I'll gladly keep trying.

[zihotki]

@atrauzzi, I'm very sorry but I don't understand why libraries tightly coupled with concrete DI, logger, etc. library are not awesome because of some decoupling bullshit. If you see that a library you want to use doesn't support your DI or log library do you immidiately abandon it? I would rather check if it's hard to implement support for other DI/log libraries and do so and make a pull request and/or a nuget package supporting them. I can talk to authors and discuss options to abstract some concepts to allow switching dependencies. This is how open source works. But you instead trying to punish them instead of improving and this is not how open source works.

I really don't understand your frustration about such dependencies. You trying to imply that it's a bad design and because it's bad it's not awesome, but most of libraries have something bad in them - design, anti-patterns, code smells, bugs, etc. Are we going to remove them as well because somebody doesn't like singletons?

[atrauzzi]

Because DI containers aren't part of an abstraction, they're infrastructure code.

You're conflating the nature of a good package with the ability to package anything.

Moreover, your idea that you can just talk to any package maintainer and tell them to make improvements is both optimistic and also exactly the point I'm trying to make here. Painting them all with the same brush as being flawed also again misses the opportunity for this listing to add value.

These are awesome packages. Not needs work packages. Packages that bundle DI will always be skipped over by the majority of people because no majority of people exists that use one single DI implementation.

[zihotki]

You are again implying that particular dependencies are a major flaw like missing tests, bug tracker, documentation. They are not. There are no black and white colors here, they are good enough to be awesome. This is awesome list but not The Best Perfect Awesome Without Strict Dependencies And Other Architectural Limitations Or Other Needs Work Issues List. The package is awesome if it solves a complex or a (very) time consuming problem for some problem area in a reliable way with good enough implementation quality.

Ok, we can mark those packages somehow in description like it was suggested above but then that mark will need to be supported - if such dependencies are removed or added we'll need to update the description accordingly. This update may take months so the information about library will be outdated for a long time and it may prevent other users from considering it. And there is no way to automate it so the question is who is going to support that? Comparing to another option we have for paid components, it's not likely that they will become completely free to use. If they will then users will very quickly discover that and may create a PR/issue to update the description. But for DI, logging libraries? Not so likely. Also, how many of the listed libraries have such dependency? If it's just a few then why are we discussing it?

So my personal opinion about this is

0. The size of problem area is not clear
1. Brings very little value
2. Very hard to keep it up to date
3. Will scare users from exploring the libraries and improving them

[atrauzzi]

I'm not only implying, I'm directly saying it! Yeah, it is a bad library that lists DI as a dependency. So no, it's not even eligible to be awesome.

I'm not hiding anything here, you're just wrong about this. No awesome packages I've ever used imply a DI implementation. One that does is not awesome by definition because it's bad coupling. As you are proving, it's a colossal waste of time to explain to anyone who thinks otherwise. Very not awesome.

[zihotki]

Given the current state of .Net Framework and the way how DI was implemented in .Net Core v2+ (using Microsoft.Extensions.DependencyInjection ) this question becomes more and more obsolete because a lot of libraries either already do it in the proper way or switching to the proper way of registering dependencies (if not but - you can always create a PR for the project you're interested in).

I'd suggest to close this issue.

[atrauzzi]

That's not always the case, and in those instances, this repository -- again, because the packages need to be awesome before being listed here -- will be giving people bad advice.

Also, I've tried to open such requests in the past and have had maintainers completely misunderstand. The response is not unlike what we're seeing here right now! So again, this is proving everything that I'm saying is true: It's easily overlooked and misunderstood.

I suggest it stay open as this suggestion greatly improves the quality of listing awesome packages.

😄

[aloksharma1]

I am not in favour of this if a package is using Json.net for example, its a well known (and necessary DI many a times) and it makes your library more awesome and stable. perhaps if we can come up with distinction of bad DI implementations (poor performing/less maintained) then removal of a library can be acceptable.

[atrauzzi]

@aloksharma1 - I'm not sure I follow what you're saying. The problem is that any requirement for a specific dependency injection implementation makes a package bad.

Moreover, json.net doesn't require dependency injection. It's a very well factored library.

---

Again, I'd like to point out how easily confused people get on this topic. As a repository self-appointed to offer awesome options, this guidance is essential. It's a right royal mess if the community doesn't start to get some education and conventional advice on this. Seriously.

[aloksharma1]

@atrauzzi i mean to say if any library depends on libraries like Json.net they are still fine by me, it would be foolish to add all json.net in a single library just for the sake of packaging. why should we reinvent the wheel. too many dependencies are bad but 1 or 2 are still fine by me, if it helps with offloading the work.

[zihotki]

It's been a while since .Net Core 2 was released and from what I see Microsoft.Extensions.DependencyInjection abstraction became de-facto standard and the only required reference for libraries and frameworks which depend on DI. The same situation happened with the Microsoft.Extensions.Logging abstraction. Given that it's quite flexible and all modern DI frameworks support it, it makes more sense to create an Issue or PR for the specific library relying on specific DI framework to support Microsoft.Extensions.DependencyInjection and to improve that library instead of delisting it.

Because of that reason I'm closing this issue but feel free to comment and share your opinion and questions. Also if you encounter any library on our list which doesn't support Microsoft.Extensions.DependencyInjection and maintainers are against implementing it please raise a separate issue so that we can participate in the discussion with maintainers and help to improve the situation.

[atrauzzi]

Mm, I think you've closed this out of hand and your "reason" gives me pause as to whether you actually get what's being explained here...

The standard interface doesn't have any bearing on this concern. I mean -- its presence is certainly helpful overall. But that doesn't make the quality of packages self-evident, even if they do take a dependency on it. There's also still the core issue of forcing people to still sift through bad packages in the interim (on an index that's supposed to be awesome). That's also presuming the maintainers are even sympathetic and willing to rearchitect their packages.

Are you (or any others) really going to shoulder the burden of all the advocacy and education necessary to inform people? Sounds like a never ending battle. You'll have more success incentivizing quality versus asking people who weren't informed enough in the first place.

Going further still, you're encouraging bad packages to stay listed whether or not they're "awesome", in this case, by way of coupling to a DI implementation.

None of this favouritism makes sense. Are we dealing with the facts at hand, or is there some underlying desire to stuff this list with as many packages as you can get away with?

[Jogai]

@atrauzzi It looks like you assume malice in your comment. This discussion could get a bit sour because of that.

I don't think either of you are wrong. Consider a project that has awesome logic, is fully tested and documented, but depends on a specific DI implementation. For some its awesome enough to take the hit, while for others this might be stopping them from using it.

The question I think is more about what is awesome. I would hate to miss out on a package which in all other regards would be awesome. On top of that, a choice for a package is always your own responsibility. You cant pick from this list and expect anything to be "truly awesome" (tm).

I rather see an indicator for "this package is locked to a specific implementation" for example with a lock icon https://thenounproject.com/term/lock/384012/

[atrauzzi]

Without the right curation, it can't be awesome dotnet. Instead, it's as much dotnet as we can fit. There's already an index that does that. It's called nuget.