[proposal] Creating nuget package per topic

[Michael Denny]

It could be great to stick on the idea of having micro-packages instead of big ones (to be cloud/device compliant 😄), and creating a nuget package of each topic:

Object pools - easy to use object pools;
Asynchronous data processing with queue - help in parallelization of item processing;
Thread pools - fast thread pools with dynamic adjustment of thread count;
Thread set manager - simplify common thread start/stop scenarios;
SemaphoreLight - extremely fast lightweight semaphore;
BlockingQueue - thread safe queue with blocking (up to 5 times faster than BlockingCollection);
EntryCountingEvent - allow to control the clients entered some block of code;
ThrottlingBehaviour - allow to limit the maximum requests per second;
IoC container - simple inversion-of-control container;
WeakDelegate, WeakEvent - event with weak reference to subscribers;
Deque - collection of elements organized as deque;
Priority Queues - simple queue with limited number of priorities;
CircularList - collection that stores elements inside circular buffer;
Read only collections - a number of useful readonly collections (List, Dictionary, HashSet);
A bunch of extension methods for IEnumerable, Type, Exception.

Then you can preserve the Qoollo.Turbo package that has dependencies on the micro-packages.

What do you think about?

[ikopylov]

IMHO, large number of micro-packages will lead to the "dependency hell". It will be hard to understand which package of which version to install to obtain required functionality. Thus, from the usability perspective, it is better to keep the entire project in a single package. From the performance/memory consumption perspective, the difference is almost imperceptible.

to be cloud/device compliant

Can you explain this in more detail?
What benefits do you see in splitting into micro-packages?

[Michael Denny]

As a rule You can always push all the packages with the same version, in this way you avoid dependency hell as the net core does.

Probably I will use this project pool, but I would not use a nuget package if it’s not separated because I don’t won’t to stick on a nuget package that has tens tools that Ive not evaluated properly, but then is there in the application ready to be used, I don’t know if you’re getting my point here, it’s not such a big deal to have the whole tools, but I’m focusing on pooling now, and now I’m use to choose only what I need, and this is one of that case for me, if I will use the pool I will copy directly in the project only that.

About the cloud “compliance” you’re right, but also all net core namespaces are in fact small by themselves, but if everyone follows this way to do macro-packages instead of micro, a project could rapidilly grow in memory footprint and have intensive GIT, so for the net core foundation are pushing everyone to do small packages and using empty package to emulate the big packages when it’s convenient.

This is just my point of view and what I understood from what’s behind having micro-packages instead of macro.

BTW thank you very much for these tools, much appreciated 😁

[ikopylov]

As a rule You can always push all the packages with the same version, in this way you avoid dependency hell as the net core does.

.NET Core actually suffer from dependency hell problem. At one point they moved from hundred micro-packages to one big package. You can find discussion here: https://github.com/dotnet/corefx/issues/15135

I’m focusing on pooling now

You still can link one package and use only pools from it.

a project could rapidilly grow in memory footprint and have intensive GIT

Memory footprint is not very large (approximately the size of the package on disk which is less than 1Mb).
JIT processes only those methods that are actually called, so there is no difference here.

thank you very much for these tools, much appreciated 😁

You're welcome!

[Michael Denny]

At one point they moved from hundred micro-packages to one big package

Thank you for point this out, I understand them points, but I was liking the great flexibility they were providing, and helping with macro-packages that were just nuget reference packages before, but now I realized that v2.0.0 macro-packages like Microsoft.NETCore.App has binaries inside, but they preserved also micro-packages like System.IO isn't? In other words they still produce separated library/package per context, but from v2 producing the macro-packages with those assembly dll inside.

You still can link one package and use only pools from it.

Yes of course, but I thought to reduce components ready-to-be-used that I haven't evaluated, but if I use the nuget package with all of it, then are there to be consumed by all the team without being evaluated, BTW it's clear that is not a big deal, I was sticky on the first netcore v1 idea 😞

JIT processes only those methods that are actually called, so there is no difference here.

You're right.

P.S.: Microsoft.AspNetCore.All still follow the micro-packages way even on v2.0, probably because what's developed on top the framework has advantages to remain in micro-packages? What's your thoughts about?

[ikopylov]

but they preserved also micro-packages like System.IO isn't?

Probably they do that primarily for backward compatibility.

What's your thoughts about?

From my point of view, mico-packages create problems out of nothing.
As a developer, it becomes much harder for me to release a new versions, harder to configure Continuous Integration. Micro-packages also bring a problem of cyclic dependencies.
As a user of this package, it becomes much harder for me to update to the latest version (micro packages should be updated one-by-one in different projects), harder to understand what micro-package should be installed to get required functionality.

[Michael Denny]

Ok fair enough, closing this, thank you 🙏🏻