Integration for Microsoft.Extensions.DependencyInjection (ASP.NET Core)

Hi,
I created an integration for Microsoft.Extensions.DependencyInjection.
You can find the code here: https://gist.github.com/cwe1ss/050a531e2711f5b62ab0
The code is based on the following links:

https://github.com/autofac/Autofac/tree/master/src/Autofac.Extensions.DependencyInjection
https://davidzych.com/asp-net-vnext-dependency-injection-with-castle-windsor/
https://github.com/aspnet/Home/issues/263
https://github.com/davezych/DependencyInjection/tree/windsor/src/Microsoft.Framework.DependencyInjection.Windsor
http://stackoverflow.com/questions/28353187/how-can-i-get-started-with-asp-net-5-and-castle-windsor-for-dependency-injection

I adjusted the code for RC1 and fixed some issues:

Components were added with .OnlyNewServices() which resulted in services that are supposed to exist multiple times not being added
GetService<IEnumerable>() was not resolved properly. I had to add special handling for IEnumerable<>
ASP.NET Core doesn't expect GetService() to return an exception if the component wasn't registered. (they use it for optional dependencies). For this reason, I added a check to Kernel.HasComponent()

I'm not sure why the call to BeginScope() in Startup.cs is necessary - if it's missing, the first request fails. Seems like ASP.NET Core doesn't start the scope for the first request or some Scoped service is requested before it does.
best regards!

I moved the code into a repository. you can find it here.

@cwe1ss sorry for not replying to your original post, I've had some personal things going on over the last couple of months which have really pulled me away from Castle.
Firstly thanks for building the integration. Unfortunately I've done zero with ASP.NET Core and the new DI framework built into it so can't really comment as to the problems you've encountered.
I assume you'd like Windsor to ship with this integration? You pasted links to code and problems, followed by "best regards", unfortunately it isn't going to get into Windsor without someone contributing the work. Your gist doesn't have a license, while your repo is licensed under the MIT license, contributions to Windsor must be licensed under the Apache 2 license.
At this point in the lifecycle of ASP.NET/DNX/CLI/etc I think it is probably best if you maintain the integration until things settle down and stabilise. My focus at the moment is on Castle Core and getting it ported to .NET Core. Windsor will obviously come next, but at the moment the build system of Windsor is completely incompatible with project.json so our learnings from Castle Core will flow into fixing that up too along with porting to .NET Core so we can accept this integration without it being just for the .NET Framework. Thoughts, opinions, feedback?

Hi @jonorossi,
we've had some serious issues with the integration during the last weeks/months - mostly related to how scopes and sub-containers are handled in Microsoft's DI framework. I'm not sure if Windsor is really compatible with their container. Seems like other DI vendors (especially SimpleInjector) don't even want to create an adapter.
I don't know much about the Windsor internals, so I didn't want to invest too much time. Instead, we decided to remove Windsor and go with the integrated DI from Microsoft for now (albeit it has a lot less features).
This means I don't really have a motivation to maintain the integration. So it's up to you to decide if and when to do something in this area!
Feel free to fork my repository, in case you need the files for future reference. I will delete the repository in a few weeks, since I believe it's broken and therefore not really helpful for anyone except you.

Hi @cwe1ss
I'm using Castle Windsor in aspnet boilerplate (http://www.aspnetboilerplate.com/) and now want to move to AspNet Core. I faced to the same problem with you. It seems the biggest problem is the Scope implementation.
Did you try to use WindsorContainer.AddChildContainer method to return a ServiceScope?

No. As far as I understand them, windsor child containers are used at service registration time and not at resolve time. ( http://mikehadlow.blogspot.co.at/2010/05/10-advanced-windsor-tricks-13-use.html ). This could be wrong though - I don't know much about Windsor.

Hmmm... yes, I'm creating some unit tests and it's like that.
I created a child container, added to main container (thus I can resolve classes registered to the main container), resolved some transient objects then disposed the child container but it did not release resolved objects.

I'm investigating docs and source code of Windsor and I suppose we should implement a custom LifeStyleManager (https://github.com/castleproject/Windsor/blob/master/docs/lifestyles.md#custom-lifestyles). This manager should return the same instance for same scope and destroy all instances when IServiceScope.Dispose() is called by AspNet.

I'm not sure if this will be enough. ASP.NET creates a scope (= a child ServiceProvider) per request. You can have transient and scoped services in such a scope so they have a different lifestyle (scoped = once per request). All of them have to be disposed on scope.Dispose().
but feel free to fork my repository and give it a go :)

OK, I created an adapter library based on your solution and it's passing all unit tests: https://github.com/volosoft/castle-windsor-ms-adapter
Can you check it? I will publish it to nuget but there is a problem with nuget.exe with AspNet RC2 packages currently.

I guess the usage of ThreadStatic might be problematic - AFAIK it's not compatible with the new async/await world. You might have to store this in CallContext, AsyncLocal ?
Also, what would happen if there were multiple child scopes within one request?

Hi,
I know ThreadStatic has problem with async/await. But I used it just while resolving dependencies and Windsor's resolving operation does not include async/await. Whole resolving progress is performed in a single thread (Windsor's resolve mechanism has also similar ThreadStatic mechanism) So, it should not be a problem.
It supports multiple scope (unit tests also have such cases). Also, there is no child scope actually in MS's DI. There can be multiple scopes nested, but they don't have child/parent relation. While this does not effect it, I just wanted to notice.

I suppose finally it's working. You can try it from nuget: https://github.com/volosoft/castle-windsor-ms-adapter#how-to-use
But surely it not works for .NET Core since it's not supported by Windsor yet.

I won't pretend I know anything about how the DI container works in ASP.NET Core and I haven't looked at @hikalkan's implementation, however have you guys looked at how the current per web request lifestyle works (i.e. ScopedLifestyleManager used by all scoped lifestyles and WebRequestScopeAccessor)?

We can not use webrequestscopeaccesor, because Microsoft.Extensions.DependencyInjection's scope approach is different and related to an IServiceScope instance.

We can not use webrequestscopeaccesor, because Microsoft.Extensions.DependencyInjection's scope approach is different and related to an IServiceScope instance.

@hikalkan I didn't mean to imply that you could use WebRequestScopeAccessor, I'm aware that HttpContext.Current is no longer present in ASP.NET Core, I meant have you looked at how they are implemented.
Scoped lifestyles in Windsor 3.0+ already implement the interfaces you've implemented yourself. You'll see the LifetimeScopeAccessor will keep track of the scope via CallContext (and only fallback to ThreadStatic on Silverlight). For ASP.NET you need to use CallContext rather than ThreadStatic (as HttpContext does) because IIS performs thread agility where it reuses OS threads while a request is blocked on I/O.
Using the Windsor scoped implementation should simply the implementation to very little, unless I'm missing something fundamental with how the ASP.NET Core DI works, which I may be as I can't find any documentation.
Nancy's Windsor integration might help to show how they are using LifetimeScopeAccessor (and WebRequestScopeAccessor) to handle non-ASP.NET pipeline (and ASP.NET pipeline requests): https://github.com/NancyFx/Nancy.Bootstrappers.Windsor. You obviously don't care about the WebRequestScopeAccessor bit but the other half.

Hi,
Surely, I opened Windsor's source code in my Visual Studio and investigated reated classes including WebRequestScopeAccessor for hours :) I also investigated source code of Microsoft.Extensions.DependencyInjection.
CallContext can not work since AspNet Core's lifetime does not depend on callcontext. You can create arbitrary scope objects (IServiceScope), store and use them whenever you need. ThreadStatic is worse since it can not work with async pattern. Even there is a HttpContext, we don't rely on it. Also, Microsoft.Extensions.DependencyInjection package is independent from web pipeline.
Surely, I would use a standard mechanism of Windsor if it's possible, but I suppose it's not.  Could you implement Windsor's IScopeAccessor using a ConcurrentDictionary<IServiceScope, ILifetimeScope> rather than a ThreadStatic?

I would not use ThreadStatic at all. I use it just while resolving an object to understand which scope is being used in this resolving operation. If I use that dictionary, how I will transfer the scope information to the resolving code to ensure they use the same lifetimescope. Resolving code can be something like that:
var myService = _serviceScope.ServiceProvider.GetService(typeof(MyService));

myService instance and all dependencies and all their dependencies should be related to the _serviceScope instance and all they should be released when _serviceScope.Dispose() is called by AspNet. Without a threadstatic, how can I relate this serviceScope with the all objects resolved in this particular GetService method call?

If you need something that works with TPL, check AsyncLocal, or more error prone LogicalCallContext.

threadstatic/async stuff is not a problem, believe me. Because, Windsor's Resolve code is single threaded (it even use ThreadStatic internally, it won't work if this was a problem).

Any news about this one?

@Kralizek - Please see #283. There is a wealth of info there.
I have not touched on this for a while because there were other things that took priority. I honestly don't believe supporting the abstractions for Microsoft.Extensions.DependencyInjection is viable because of impedance mismatches in the design. It leads to behaviours that are difficult to maintain.
It has also earned Windsor the title of a non-conforming container. Not even sure what that means. I am planning to dust off the work I have been pursuing on this in the next few weeks.

How is people supposed to use Castle Windsor in ASP.NET Core applications? Should we do all the built-in registrations again?
Also, many library creators are creating setup helpers based on IServiceCollection.
Non supporting the de-facto standard in .NET (Core) will eventually mean pushing Castle Windsor into oblivion. And that would be sad.

Non supporting the de-facto standard in .NET (Core) will eventually mean pushing Castle Windsor into oblivion. And that would be sad.

Windsor relies on contributions, @fir3pho3nixx isn't saying Windsor won't support it, more just that we haven't worked out how within the constraints of what we've got on both sides. I encourage you to continue the discussion, I personally don't have the time to work on this in the short or medium term, but would like to see those that have spent energy on this already get together and nut out or workaround remaining issues so Windsor can support this.

Don't get me wrong. I have extreme respect for the people who pulled off the .NET Core support.
But my comment was about attitude, intentions and future plans. When people write "I believe X is not viable" and X is the biggest thing happened in the .NET space in the last couple of years, you are putting yourself in the wrong mindset.
Let me write it explicitly again, my criticism is not about "not having done something because lack of resources", rather "CW is a great product (it really is or i wouldn't be here) and we define our own standards, people will follow us".
The focus should be giving users the possibility to jump on CW from a dotnet newed project in three steps. And those three steps, like it oe not, are necessarily passing by supporting Microsoft.Extensions.DependencyInjection. Then it's just about deciding the level of support.
Again, I'm a "dedicated customer" of CW. Dedicated enough to have googled for a solution for those three steps. I found "https://github.com/volosoft/castle-windsor-ms-adapter" but the vibe i get here is that it's compiling solution rather than a sustainable one (aka, can i go live with it?). If i weren't so committed into using CW, I would have already jumped ship.

@Kralizek https://github.com/volosoft/castle-windsor-ms-adapter is maintained by us and it's used in production by our customers. It's not something just compiles. We have spent significiant time to adapt Windsor to MS DI (it was hard). So, I think you should give a chance to it :)

Great!

@Kralizek I'm not writing on behalf of the project and/or the people working on it atm. This is a personal opinion.
But as a long time OSS contributor, this is the kind of behavior that pisses off everyone working it.
We (oss devs) don't get paid for our work, so you're not a customer (download it or using in an very importante/production project also doesn't make you a customer). Also, we don't care if you googled a solution to fix an issue for the people who do pay your salary.
So, next time (unless you're willing to contribute with an actual solution that involves contributing source code), please: save the smarts thoughts/criticisms about long term strategy and priorities to yourself.

Here is something I was toying around with 2 weeks back in July: https://github.com/fir3pho3nixx/castle-windsor-owin-deps/commits/master
I have an easier solution to maintain using scoped lifestyles, I am first playing around with it here to understand it better: https://github.com/cryosharp/fluentwindsor/tree/fluentwindsor-next/FluentWindsor/FluentWindsor.AspNetCore
Just think implementing this: https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection.Abstractions/ is incredibly tough as @hikalkan corroborated.
Spent weeks if not months looking at this @Kralizek. @hikalkan definitely has a working solution. I recommend using this solution for now. If you are having problems or you are interested in "rolling you're own" you can also look at this: https://github.com/dotnetjunkie/Missing-Core-DI-Extensions/tree/master/src/SampleApplication.CastleWindsor. From my tinkering and testing it is definitely another workable approach which is easier to maintain.
My so called wrong attitude is months of studying the problem and talking to the aspnet team directly. What have you contributed lately?

I do believe an implementation around Missing Core DI Extensions is the best way to go in terms of maintainability for the Castle Windsor Project. I will list advantages and disadvantages below.
@hikalkan feel free to weigh in, you and I have done heaps of work on the Microsoft.Extensions.DependencyInjection.Abstractions space and I feel you are the leading authority on this approach. Counter arguments from you are most welcome indeed.
Advantages:

Castle Windsor has a first class mature registration API. The registration API extension's for ServiceCollections are incredibly naive from my point of view. Also it is woefully opinionated for the AspNet team to expect container's to forgo their years of hardening and design around this and to merely adapt to their desired service state configuration for a container. Missing-DI-Extensions promotes the use of the underlying containers public registration API's. This gives access to things like IWindsorInstaller's and not to mention all the namespace registration slicing, conventional registration power along with things like specifying interceptors using Castle Core.

We do scoping properly, they simply don't. Our scopes are a single responsibility which applies to the lifestyle of a dependency under certain registration conditions with predictable burden based decommissioning concerns(not including parent/child containers in this statement). Their scopes blend in a service locator pattern in which mutates lifestyle outcomes depending on whether it was consumed inside or outside of a scope but also imposes constraints on singletons. It also requires the new'ing up of child container(not in the windsor sense) which is just plain rubbish when it comes to memory management and compared to how Windsor does it today.

Singleton's live on, transients consumed by them get disposed. Eh? What?

You don't have to figure out the internals of AspNet to adapt their desired service state configuration to Windsor via the bizarre Microsoft.Extensions.DependencyInjection.Abstractions suggestion. @hikalkan you conquered this, but already I can tell you have to mutate lifestyles to fall back on to other lifestyles achieve this.

AspNet do what they need to do and you are in control of your container using the native functionality. It is unfortunately a world of two halves. You just get to pick the one you want for your stuff without the lacking API's or blatant inefficiencies.

Disadvantages

You have to register framework services/extensions yourself. This can be problematic if you misunderstand what they needed/meant or they did not bother to document before releasing stuff. I personally don't believe this to be a big problem at all.

Summary
After walking @hikalkan's path myself, I can honestly say if you want a registration API that relies on ServiceCollection extensions then you should definitely use that.
If you want to use Windsor, go all in I say ... that includes the registration API along with all the buttery goodness it has to offer.

I finally have time to sit down and read where this conversation is going.
I am really sorry that my intentions were misinterpreted and I here offer my deepest apologies for the tone of the posts. In no occasion I wanted to be disrespectful to the work put into this amazing project by every single contributor. I understand that the tone used in my comments was heavy and ungrateful but, believe me, I never wanted this to be the point.
I might have been swinged away by comments written before things were actually the way they are right now, but this is not a good excuse for using such a tone in my posts.
Again, if any of you felt insulted, I am deeply sorry for that.

@Kralizek - We all get peeved sometimes seriously not a problem. If you have been following the notifications for this project you would have noticed that I have been doing a lot of research in this space over the past few months. I honestly cannot take the credit for everything. @dotnetjunkie did a lot of leg work pursuing this with the aspnet team. It was only when I started bombarding the same team with a multitude of issue's that I was pointed towards this issue.
My problem with supporting the adapter is the aspnet team gives you a suite of tests that you are supposed to make pass for your container, this unfortunately dictates really bad things in terms of design. It also reveals how inferior their design is when comparing it to something like Castle Windsor.
Anyone supporting this is either hacking around their malformed design(which they are not interested in fixing) or actually implementing IoC incorrectly. I believe Windsor is better than that. I would literally have to break Windsor to support this nonsense.

@fir3pho3nixx
I would l to respond to your list of advantages and disadvantages:

The registration API extension's for ServiceCollections are incredibly naive from my point of view. [...] their registration API is absolute garbage.

Do note that it has never been Microsoft's intention to have a registration API that completely replaces that of a third-party container. In that case it would be rather useless to use a 3rd party container. The abstraction is merely meant to be able to push all the framework and 3rd party component registrations into a third-party container and to let application developers use their container’s native API on top of that, so they can have features like batch-registration and interception. So the idea always was that application developers registered their application components using the native API.
Problems however arise because there are now two APIs that might have completely different (and sometimes incompatible) behavior. When an application developer uses the MS API, can he expect the registrations to behave the same as when done through the native API? And what if object graphs are composed of both MS API registrations and native API registrations? Which rules should apply? Native rules or MS rules? Differences between the two could be very subtle.

Singleton's live on, transients consumed by them get disposed.

I tested this last week with Core v2. Transients, injected into singletons get disposed after their singleton gets disposed (i.e. they're scoped to the container). I'm unsure whether this behavior was different before.

You have to register framework services/extensions yourself. This can be problematic if you misunderstand what they needed/meant or they did not bother to document before releasing stuff. I personally don't believe this to be a big problem at all.

This is actually the hardest part in the framework/application container split. A big warning here: Do not advice your users to re-register framework components in Castle Windsor. This leads to extraordinary amounts of pain, because users will have to redo complete lists of registrations for object graphs for what they are only interested in getting the top-most object. This leads to large amounts of code duplication–for each framework component or third-party component they are using, and this block of registration needs to be updated with each new version of such component. This would lead to a lot of work and strange bugs after upgrading to a new version. On top of that, since there might be subtle differences in the registrations APIs, it might lead to weird bugs if users try to do this themselves. Having the writer of a DI Container create a integration package however, makes little sense, because it would force a tremendous burden on the maintainers of such DI Container.
Another bug that you might run into when doing this is that of Torn Lifestyles. This can happen when a framework or third-party component is registered as Scoped, and we re-register it again as Scoped in Castle Windsor. This might lead to having 2 instances of that component during the same request.
Instead, framework and third-party components should be cross-wired (this is a term I coined for the occasion). Cross-wiring means that we register a delegate in Castle Windsor that redirects the call to the MS container to resolve it for us. This way, the MS container is in control over the composition of that component and all its dependencies. The only thing we do is get it from the MS container and inject it into our object graph.
I always tell my users that their application should have very little dependencies on those application or third-party components, and that the amount of cross-wired dependencies should be very low. This means that it shouldn’t be a problem to cross-wire the few dependencies that exist.
Although I still feel this way, that statement however has proven to be a little problematic for application developers. A good example is when Identity Framework Core is used and especially when mixed with its templates that are installed in Visual Studio. To get the default template working with a non-conforming container is quite annoying.
Another problem with this approach is, that while cross-wiring, you need to be aware of the lifestyle of a component in the MS container, to prevent running into Captive Dependencies. A better approach would be to register these dependencies as Func<T> singletons that resolve from the MS container at runtime instead of at time of composition. Although I do endorse this model, it confuses developers, again because of the default Identity Visual Studio template, which needs to be refactored quite a bit.
Because of this, the Simple Injector community has been experimenting with some ‘auto cross-wire’ feature for Simple Injector (see code). This will try to cross-wire a registration automatically when the container encounters a missing registration in the Simple Injector container.
You might think this reintroduces the Conforming container, but this is not the case, because it completely circumvents the MS registration API, and only makes use of its Resolve functionality (so it’s a Service Locator at most–not a Conforming Container). It does however require some knowledge on what the meaning is of the IServiceCollection, because it needs to check whether or not a registration exists, and it also skips resolving collections, because behavior of collections is incompatible between MS and Simple Injector, even when just resolving collections.
This is still in the experimentation phase however. Although some users reported great success, it’s still a bit unclear the exact downsides of this approach.
One thing I would really like to see is such extension to be moved in a Microsoft assembly. In an ideal world, even non-conforming containers should need no integration packages what so ever. Castle Windsor should only have a piece of documentation explaining how to plug in the container into the Microsoft pipeline using the Microsoft supplied code. This is one of the promises that Microsoft made when building their Conforming Container. They wanted to end the need for endless permutation of integration libraries.
Unfortunately, that’s not the world we live in (and I don’t think we have to expect too much from Microsoft in this respect), so we are forced to still create our own integration packages for each new framework on top of .NET Core.

You are effectively running 2 containers. The AspNet internal one which you are side stepping, and the consumer one which is your choice.

Do note that out-of-the-box, ASP.NET Core already runs with 2 container instances. From the initial set of registrations a ‘hosting container’ is built. Later on, that same set of registrations is used to build a container that contains the registrations for MVC and your application components. This happens even if you use the built-in MS container, and since those containers aren’t cross-wiring, it can already lead to Torn Lifestyles.

This could be considered bad, although I would like to hear elaborations from people on this thread as to the severity.

I don’t agree with this. I always try to explain to developers that, from their perspective, there is only one container, which is their application container (in your case: Castle Windsor). The other thing is not a container, it is the framework’s configuration system. Older .NET frameworks had their own configuration system as well (ASP.NET Forms mainly XML based, and MVC and Web API contained their own Services collections that you could add and remove stuff to/from). In ASP.NET Core the configuration system is more complex, has more features, but it is still a configuration system. In the past we had our own application container for our own application components. As I see it, if we use an non-conforming container, this is the exact same model.
But even if you see the framework’s configuration system as a container, there’s nothing wrong in having two separate containers. You achieve a pretty nice separation between the components you are interested in (your application components) and the things you are typically not interested in (framework infrastructure). By separating these two worlds, your application container is not polluted with hundreds of registrations that are not of your concern. Keeping things separate is IMO the most sensible thing to do.

@dotnetjunkie
I noticed our first need for cross wiring. It was actually @generik0 that exposed the issue. We ended up embedding callbacks(factory methods) to the IServiceCollection that resolve from our container. This put us back on top without registration API.
I will tag you in our issue tracker if I think we find something relevant that might need some consideration. :)

Hi @fir3pho3nixx,
I'm a bit worried about your FrameworkDependencyResolver. You seem to be building a new ServiceProvider (on line 43). This can easily lead to dependencies having a Torn Lifestyle. Because you will create a second M.E.DI container instance, with its own dependency cache.
When a singleton registration is made, for instance, both the framework-built, and your FrameworkDependencyResolver-built instance will get its own instance of that registration. This could lead to very subtle, and hard to trace bugs, which might only appear in production.

@fir3pho3nixx @dotnetjunkie
This is really interesting. I have just a question for brainstorming,
Could it be an idea to set the app service provider, to the castle frameworks service provider?
Then we might not need to cross wire for @inject either ?
I.e. under:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            app.ApplicationServices = //CFrameworks service provider
                //or
           app.UseCastleWindsorServiceProvider();

It would of cause mean that eeryting in the service collection and builtin provider needs to be present in the container.?

Please note, this is just a thought. Don't shoot me if I am completely wrong about it all....

I did a test. not good code, but stil a test if the FrameworkDependencyResolver could replace the ApplicationServices.
It does seam to work...!!! App spins up, everything is resolving
Any thoughs?

I'm a bit worried about your FrameworkDependencyResolver. You seem to be building a new ServiceProvider (on line 43). This can easily lead to dependencies having a Torn Lifestyle. Because you will create a second M.E.DI container instance, with its own dependency cache.

@dotnetjunkie Correct!
You are snap-shotting the dependency graph when you build the service provider. This leads to all sorts of problems.
First is an ordering/timing problem of when things are cross wired vs when the service provider gets created. I tried to push service provider creation all the way down to the first resolve using null coalescence for the reference as a singleton. A "just in time" kind of thing. I don't think this has entirely solved the problem but it does minimise collatoral damage when you start integrating 3rd party libraries or start using things like @Inject in your razor views(nasty!).
Second is creation of the service provider is memory intensive.  By making service provider creation as late bound as possible and not re-creating it reduced our memory footprint from 1+GB to 300MB or such.
I also tried auto cross wiring, but that can have some disastrous consequences depending on when things happen and for performance. I noticed torn lifestyles then and immediately did a 180 and backed out of that idea. It also prompted me to start reading up on some of the simple injector issues. Not easy at all.
I think we need to firm up the definition of what a "cross wire" is and document it from there. It would also contribute to the working knowledge of parent/child containers.
Lastly thank you for being the bastion of calm and sanity in this. I am rather peeved at how this has gone and all the time of that all of the developers that have wasted on this.

@generik0
What have you found? I did think in the back of my mind that the ApplicationBuilder was the reference point for a service provider.
When I rolled this test I explicitly left this unused variable behind: https://github.com/castleproject/Windsor/pull/394/files#diff-9cd8e6d1d0ec81f11c73998ce083a4e0R42
@jonorossi I think we need a branch called aspnet-core-windsor, so we can explore this further with more experimental PR's.

@dotnetjunkie
The most concerning thing for me right now, is why one is allowed to register the same things over and over again and the last one in wins. IServiceCollection in terms of design is an absolute mystery to me. Mental TBH.

Hi @fir3pho3nixx
I probably found nothing. I think it was more of a question. As far as i could read from @dotnetjunkie 's post he was worries about the FrameworkDependencyResolver having a service provider which ment there was more than one service provider in play.
So my question was just, cant we replace the app service provider with the FrameworkDependencyResolver  at app configure. I tries it, and it appears that the application does atleast not crash. But needs  much more testing. as the existing service provider does have a lot of resolved and registered services the FrameworkDependencyResolver does not..
Its just a though, and a question, Could this path resolve @dotnetjunkie 's worries? Or is it just another hack to get this facility to work?

@fir3pho3nixx, waait a second. did I read @dotnetjunkie message incorrect. Is the message not about having 2 x ServiceProviders, but having a service provider, and a windsor container?
Meaning we have 2 Service Providers, and 1 Windsor Container? And this can lead to torn lifestyles?

@generik0,
In case you add a singleton registration to the service collection, every service provider you create from that collection will get its own cache and thus its own 'singleton' instance. Although not always a problem, it does mean the singleton gets torn, meaning that you lose the guarantee that there is only one instance.
This same problem exists when you have both a service provider and a Windsor container, if you copy registrations instead of cross-wiring them; the effect is the same.

@fir3pho3nixx,
In an ASP.NET Core application it is done by the framework by one of the classes that gets called in the Main method. I think that's the AppBuilder.
I'm unsure that dereferencing is a solution, because by that time instances might have been resolved already. That is probably what you are referring to as "a timing issue".

But if you cache sinhletons outside one container instance, how do you know when to dispose them? Besides, I think that if you reuse singletons and share them across container instances, you'd even by violating the (very implicit) .NET Core DI Abstraction contract.

No no, cache the service provider instances in an ordered list. Then interrogate to the IServiceCollection for descriptors that are singleton, and then try and resolve them one at a time from the ordered list of service provider instances.

I am thinking IServiceCollection needs to expose an event that calls out once BuildServiceProvider is called. This would at least allow us to track the problem and untear singletons without them having to move mountains to fix this.

It would be a very simple PR that solves this problem.

@dotnetjunkie I disambiguated my statement. Sorry.

Let me raise a PR against the current version of master for DependencyInjection to clarify what I mean.

@dotnetjunkie
What I am proposing is a two step solution. We can track torn singletons as a temporary measure but we need to work with Microsoft to see if there is a way that works for them also. Surely there must be a way of sorting this!

I would like to see singletons be IServiceProvider agnostic using a static instance cache that floats between them. It would really not be a lot of work and yet it would yield very high value.

Should I try and raise this with @davidfowl? Maybe @shanselman can arbitrate.

@shanselman Houston, we have a problem ....

/cc @natemcmaster

For anyone interested in a debuggable solution I have one here: https://github.com/fir3pho3nixx/Windsor.AspNetCore/tree/aspnet-hosting
@dotnetjunkie My gut feel right is we need to start looking at hosting. Creating our own IServiceProvider'less hosting provider is an potentially an option?

@fir3pho3nixx can you stop tagging the entire team here. It's not productive. What's the goal here? The thread is long and the latest issue might be something specific and unrelated to the original problem.

@davidfowl Very much connected to the original problem. Let me explain(although I had hoped you read downward from the first time I tagged everyone).
Creating 2 service providers, will produce 2 separate singletons respectively. This leaves me with torn lifestyles if I manage my own service provider from within the FrameworkDependencyResolver.
I think I have a way of fixing this but it would involve submitting a PR: https://github.com/fir3pho3nixx/DependencyInjection/pull/2
It would then help unblock the original PR for this issue: https://github.com/castleproject/Windsor/pull/394

Hosting is the one in the "wrong"

It also looks like I have made the same mistake. What is right way to do this? What are you guys planning to do with hosting? This would probably set me on the path to a proper fix.

Is this basically trying to make castle work with ASP.NET Core without being a "conforming" container?

In a word yes. We simply don’t treat scopes and singletons as the same thing. I tried “conforming” this container almost a year ago but the impedance mismatch in life cycles alone make it impossible. I am still hopeful we can make this work.

That fix is in the wrong place. Hosting is the one in the "wrong" not the DI implementation itself so that's not the right place to tackle the issue.

Curious, it solves the abuse that has already happened in hosting(and might be proliferated through all sorts of third party libraries). After falling victim to this myself I would like see some safety built into dependency injection. Would you reconsider?

The thing is, today the effect is that you get different instances because there are different universes. I  still haven't looked closely enough to see what is different about castle core's implementation that makes it a deal breaker. That isn't to say they isn't a problem but it's been there since the beginning so we just have to understand why it matters more now.

Curious, it solves the abuse that has already happened in hosting(and might be proliferated through all sorts of third party libraries). After falling victim to this myself I would like see some safety built into dependency injection. Would you reconsider?

Maybe but the bar is extremely high for making changes to our default container. It's pretty much frozen unless something is outright broken (and wouldn't be a breaking change to fix).

The thing is, today the effect is that you get different instances because there are different universes

Are scopes universes also?

I still haven't looked closely enough to see what is different about castle core's implementation that makes it a deal breaker.

I would love to explore this a little more. Scopes are completely incompatible between our containers.

That isn't to say they isn't a problem but it's been there since the beginning so we just have to understand why it matters more now.

It always mattered. Just getting to it now.

Maybe but the bar is extremely high for making changes to our default container. It's pretty much frozen unless something is outright broken (and wouldn't be a breaking change to fix).

Please bear with me. The least that can come out of this is that I will have a better understanding.
I am incredibly interested in the CallSiteRuntimeResolver right now. Is there any way I could override the VisitSingleton method to use a static collection of resolved services? This would probably sort the problems in hosting out and also not be a breaking change. Hope you are open to discussing this.

Are scopes universes also?

No. Scopes are very simple. The scoped IServiceProvider is just a disposable root for scoped and transient services. If something is declared as scoped, then it's a singleton within the scope container it gets resolved from (instance per lifetime scope in autofac speak).

I would love to explore this a little more. Scopes are completely incompatible between our containers.

public interface IThing  { }

public class Thing : IThing, IDisposable
{
   public void Dispose() => Console.WriteLine("Thing.Dispose()");
}

var sp = new ServiceCollection().AddScoped<IThing, Thing>()
                                                       .BuildServiceProvider();

using (var scope = sp.CreateScope())
{
   var thing = scope.ServiceProvider.GetService<IThing>();
   var thingAgain = scope.ServiceProvider.GetService<IThing>();

   // These are the same instance since they were resolved from the same scope container
}

When I say different universes I literally mean we create different instances of IServiceProvider:
var universe1 = new ServiceCollection().AddSingleton<IFoo, Foo>().BuildServiceProvider();

var universe2 = new ServiceCollection().AddSingleton<IFoo, Foo>().BuildServiceProvider();

Those are 2 different worlds even if they share the same service descriptors. This is what hosting does because they are stages.

It always mattered. Just getting to it now.

When I say it didn't matter, what I meant is that you get different instances at each stage which is by design. It means if you add a singleton in the hosting container, you get 2 different versions because they are 2 different containers. That's the quirk. It surfaces when you resolve a service from the Startup constructor and then from the Configure method.

I am incredibly interested in the CallSiteRuntimeResolver right now. Is there any way I could override the VisitSingleton method to use a static collection of resolved services? This would probably sort the problems in hosting out and also not be a breaking change. Hope you are open to discussing this.

I don't see that as a viable option to change how the default service provider works to plug in a 3rd party container. AFAIK those are implementation details of the default container.

No. Scopes are very simple. The scoped IServiceProvider is just a disposable root for scoped and transient services. If something is declared as scoped, then it's a singleton within the scope container it gets resolved from (instance per lifetime scope in autofac speak).

Good explanation.
In Windsor a service that is registered with a scoped lifestyle will throw an exception if it is resolved from the container(or root scope) unless a scope is created first. Scoped instances live for exactly as long as the scope until it gets disposed. Child scopes yield new scoped lifestyle instances. Transient instances will be instantiated N+1 times dependending how many different service types consumed them as dependencies and their disposables are scoped tracked.
Singletons however are scope agnostic. I think this is a sticking point for me.

When I say different universes I literally mean we create different instances of IServiceProvider:

Two containers. Got it.

Those are 2 different worlds even if they share the same service descriptors. This is what hosting does because they are stages.

Stages of what? We have 2 containers here.

When I say it didn't matter, what I meant is that you get different instances at each stage which is by design.

Why have N+1 containers?

It means if you add a singleton in the hosting container, you get 2 different versions because they are 2 different containers. That's the quirk.

Yup but do new scopes yield new singletons? This is not right.

I don't see that as a viable option to change how the default service provider works to plug in a 3rd party container. As far as I'm concerned those are implementation details of the default container.

You guys have violated the law of singleton when it comes to scopes. https://en.wikipedia.org/wiki/Singleton_pattern

quote end

Hope you understand that there are some fundamentally different things happening when it comes to memory management here. It affects downstream performance heavily if you keep reinstantiating singletons that pull config in the cloud. Hope you will reconsider this approach.

Why have N+1 containers?
One use case could be integration testing. You might have 1 container for services used by the test code, and 1 container for services used by the application code. So having 2 "singleton" instances would then make sense since you don't pollute the application environment with components registered for the test environment.

One use case could be integration testing. You might have 1 container for services used by the test code, and 1 container for services used by the application code. So having 2 "singleton" instances would then make sense since you don't pollute the application environment with components registered for the test environment.

This happens in aspnet/hosting so this is not test code.

@davidfowl
I believe we can fix this by passing the root scope to the call run-time resolver.

Singletons however are scope agnostic. I think this is a sticking point for me.

They have to be, if they weren't, singletons would be the same as scoped. Put another way singletons are scoped within the root container.

Stages of what? We have 2 containers here.

If you look at how hosting wires things up there are 2 phases to Startup:
public class Startup
{
   public Startup(ILogger<Startup> logger) // Startup gets resolved from the first container (the hosting container)
   {
   }

   public void ConfigureServices(IServiceCollection services) // This is the second container definition (the application container)
   {
   }

   public void Configure(IApplicationBuilder app, ILogger<Startup> logger2) { } // We resolve services from the second container here (the application container)
}

Yup but do new scopes yield new singletons? This is not right.

It's not a new scope, its an entirely new container. There's the hosting container which is used to resolve services in the Startup constructor and there's the application container which uses the service collection provided in ConfigureServices to be created.

Hope you understand that there are some fundamentally different things happening when it comes to memory management here. It affects downstream performance heavily if you keep reinstantiating singletons that pull config in the cloud. Hope you will reconsider this approach.

I'm not sure what you mean.

They have to be, if they weren't, singletons would be the same as scoped. Put another way singletons are scoped within the root container.

But your call site run-time resolver says you resolve singletons as scoped. https://github.com/aspnet/DependencyInjection/blob/dev/src/DI/ServiceLookup/CallSiteRuntimeResolver.cs#L39

It's not a new scope, its an entirely new container

New scope = new container?

New scope = new container?

No, a new scope is not a new container. We should stop conflating these things.
This is a new container:
var sp1 = new ServiceCollection()
           .AddScoped<ScopedService>()
           .BuildServiceProvider();

var sp2 = new ServiceCollection()
           .AddSingleton<SingletonService>()
           .BuildServiceProvider();

sp1 and sp2 are different containers, they don't share service descriptors, they are independent of each other. They are both distinct top level root containers and can each create their own scopes independently.

But your call site run-time resolver says you resolve singletons as scoped. https://github.com/aspnet/DependencyInjection/blob/dev/src/DI/ServiceLookup/CallSiteRuntimeResolver.cs#L39

Lets not discuss the implementation details of the default container. That just makes the conversation more confusing.
Let me try to explain again:

Scoped services are singletons within a specific scoped container instance.
Singleton services are the same instance across all scoped containers.

Example:
var sp  = new ServiceCollection()
             .AddSingleton<SingletonService>()
             .BuildServiceProvider();

var singleton1 = sp.GetService<SingletonService>();

using (var scoped = sp.CreateScope())
{
    var singleton2 = scoped.ServiceProvider.GetService<SingletonService>();
    Assert.Same(singleton1, singleton2);
}

In the above code snippet, the singleton object is the exact same object even though it singleton1 was resolved from the root container (sp) and singleton2 was resolved from the scoped container.
Here's an example of scoped services:
var sp  = new ServiceCollection()
             .AddScoped<ScopedService>()
             .BuildServiceProvider();

using (var scoped = sp.CreateScope())
{
    var scoped1 = scoped.ServiceProvider.GetService<ScopedService>();
    var scoped2 = scoped.ServiceProvider.GetService<ScopedService>();
    Assert.Same(scoped1, scoped2);
}

using (var scoped = sp.CreateScope())
{
    // New instance
    var scoped3 = scoped.ServiceProvider.GetService<ScopedService>();
    var scoped4 = scoped.ServiceProvider.GetService<ScopedService>();
    Assert.Same(scoped3, scoped4);
}

// Resolving a scoped service from the root container will throw by default in ASP.NET Core because
// ValidateScopes is on (a feature of the default container)
sp.GetService<ScopedService>();

Stages of what? We have 2 containers here.

If you look at how hosting wires things up there are 2 phases to Startup:
public class Startup
{
   // Startup gets resolved from the first container (the hosting container)
   public Startup(ILogger<Startup> logger)

   // This is the second container definition (the application container)
   public void ConfigureServices(IServiceCollection services)

Sorry for kicking in, but to make sure - so typical WebHost creation like
            return WebHost.CreateDefaultBuilder(args)
                    .UseConfiguration(configuration)
                    .UseStartup<Startup>()
                    .Build();

Creates and uses "the first container (the hosting container)" just to help in creating the Startup object, and then (more or less) forgets the container and lets the Startup bootstrap its own, new, second container instance "(the application container)" thats later used through out the app's lifetime?
That would explain some confusing things I've seen when I tried to setup some common logging for app startup and app runtime.. Ok, but then, once application starts, what happens to the first container? is it totally forgotten and left for GC to cleanup, or is it kept and later something other than Startup is resolved from it as well?

creates and uses "the first container (the hosting container)" just to help in creating the Startup object, and then (more or less) forgets the container and then, only after creation of the instance of Startup, we lets the Startup bootstrap its own, new, second container instance "(the application container)" thats later used through out the app's lifetime?

@quetzalcoatl that's absolutely correct.

That would explain some confusing things I've seen when I tried to setup some common logging for app startup and app runtime..

Yes, it's a PITA.

Ok, but then, once application starts, what happens to the first container? is it totally forgotten and left for GC to cleanup, or is it kept and later something other than Startup is resolved from it as well?

It sticks around until the WebHost is disposed but nothing else is ever resolved from it (it could really be disposed earlier).

@davidfowl
You have cleared up quite a bit, I managed to clear up quite a few things in my PR as a result. Disposables are working properly and I don't have any issues with singletons anymore. The last thing I need to look at is why enabling scope validation in the facility is triggering exceptions.
Everything you have said so far is making perfect sense. I not sure what stopped us from conforming the first time, we had all sorts of problems making those tests pass but that was a while ago. I might take another look at this later on. Thanks for explaining. 👍

@dotnetjunkie
I believe there has been a significant jump in the way this worked 12 months ago. This was probably a massive game changer for windsor.
Is there anything you think we have missed here?

@davidfowl
We are going ahead with this cross-wiring non-conforming thing for now (I do know there is a problem with scopes just not clear on why yet). I do think our next issue needs to be a conforming one. I am not going to try and address this here because this is an issue already has a long tail. Thank you for your input, look forward to to making this happen.
@dotnetjunkie
I think we have cleared up most of the misconceptions I have had. Thank you for your input.
@all
If you guys can see something I missed @ PR: https://github.com/castleproject/Windsor/pull/394 please chime in. @generik0 this includes you.

If you need any more help or clarification let me know. Castle Windsor is a popular container and it would be huge if an adapter could be built.

one of the reasons that was preventing me
from taking brown field projects (upgrading from mvc5 to core)
is not being able to use castle windsor.
it seems that it's going to be possible now. i'm excited
thank you guys!. :)

@hikalkan looking a your impl, it seems as though scoping is the hardest thing to implement right? A cursory glance tells me there's no built in unit of work style scope that isn't tied to some ambient state (call context, async local etc). I haven't looked but I'm also guessing there's no support for child containers or nested containers in windsor? This is the model that most closely matches the semantics of Microsoft.Extensions.DependencyInjection:

StructureMap - http://structuremap.github.io/the-container/nested-containers/
Autofac - http://autofaccn.readthedocs.io/en/latest/lifetime/working-with-scopes.html

A cursory glance tells me there's no built in unit of work style scope that isn't tied to some ambient state (call context, async local etc)

We use async local for scoped ambient state here: https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor/MicroKernel/Lifestyle/Scoped/CallContextLifetimeScope.cs#L48

I haven't looked but I'm also guessing there's no support for child containers or nested containers in windsor

We have them: https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor/Windsor/IWindsorContainer.cs#L56
They behave wierdly in some cases. Wont pollute with detail.

After looking at @hikalkan's code looks like there is ambient state for scopes are happening here: https://github.com/volosoft/castle-windsor-ms-adapter/blob/master/src/Castle.Windsor.MsDependencyInjection/MsLifeTimeScope.cs#L32

@hikalkan Of course! Modelling the provider impedance mismatches was definitely the right way to go.  Could you kindly provide some more context around your code quote?
using (MsLifetimeScope.Using(OwnMsLifetimeScope))
{
	var isAlreadyInResolving = IsInResolving;

	if (!isAlreadyInResolving)
	{
		IsInResolving = true;
	}

	object instance = null;
	try
	{
		return instance = ResolveInstanceOrNull(serviceType, isOptional);
	}
	finally
	{
		if (!isAlreadyInResolving)
		{
			if (instance != null)
			{
				OwnMsLifetimeScope?.AddInstance(instance);
			}

			IsInResolving = false;
		}
	}
}

@davidfowl I need more time to assimilate. Please bear with me.

@davidfowl I need more time to respond to this (sorry man I know what you are asking for). Please bear with me.

@fir3pho3nixx it's cool. I have a suggestion on how to fix it after you respond but I haven't dug into the code to see how hard it would be to implement.

@hikalkan Of course! Modelling the provider impedance mismatches was definitely the right way to go.  Could you kindly provide some more context around your code quote?

The code probably doesn't need to be that complex. For example there is no nested scope requirement. Scopes can be at a single level they don't need to support overlapping. Because of the ambient state model though I see why you feel the need to handle it. Consider this:
using (var lifetime = new DefaultLifetimeScope())
using (var lifetime = new DefaultLifetimeScope())
{
    container.Resolve<IFoo>();
}

There's no way to resolve from a specific scope there. The last one will win because it's the most recent. This might be an edge case though but somebody could run into it.

Guys, I am closing this in light of PR: https://github.com/castleproject/Windsor/pull/394
@jonorossi Thanks for reviewing and cleaning up all my misconceptions about Windsor.  Seriously man, good work.
@dotnetjunkie You informed and led this process from eons ago. Thank you.
@davidfowl Thank you for engaging us. Hope you don't mind if we call on you in the future. Seriously thank you.
This issue only took 2 years, 4 months, 18 days excluding the end date to solve.


Download e2e & push to private registry

What this PR does / why we need it:
New commands allows the following:

"pull": Docker pull all E2E images based upon the cluster version (v1.13 or greater) to the local docker client
"download": Once "pull" has happened, export all images as a tar file
"push": Tag all images with private registry then and push to a registry
"delete": Deletes all images that were pulled from local docker client

Which issue(s) this PR fixes

Fixes #606 #604

Special notes for your reviewer:
This supersedes #626
Release note:
New command allows users to download all E2E images based upon the cluster version (v1.13 or greater), then tag them and push to a local registry.

Signed-off-by: Steve Sloka<EMAIL_ADDRESS>

@johnSchnake I'm going to collapse all these into a single PR. Since they are all related I don't want to run across 3 rebases on the same code. I'll integrate the feedback, heads up shortly.

@johnSchnake I refactored everything modeled after kind. PTAL! =)

@johnSchnake I think I got everything resolved now. Please take a look. Thanks! =)

@johnSchnake I did a bunch of refactoring. I added a Docker interface so we can stub out what happens there and then tested all the image functions (e.g. push, pull, etc) along with all the other comments.

@stevesloka Looks good to me! Just needs a rebase.  I really liked where it is now in terms of clarity of messages to the user 👍


reflowing JSdoc fails

From @slang800 on May 8, 2014 19:20
###*
 * Constructor, options are passed in from the cli tool or manually when using nsync as a library.
 * By default, it just sets schema properties that all transports use.
 * @param {[type]} options [description]
 * @return {[type]} [description]
 * @extend
###

get's reflowed into this:
###*
 * Constructor, options are passed in from the cli tool or manually when using
 * nsync as a library. By default, it just sets schema properties that all
 * transports use. @param {[type]} options [description] @return {[type]}
 * [description] @extend
###

...which is pretty clearly wrong. It would be great if autoflow had the same behavior as ST2's wrap-plus package, which reflows to look like this:
###*
 * Constructor, options are passed in from the cli tool or manually when using
   nsync as a library.
 * By default, it just sets schema properties that all transports use.
 * @param {[type]} options [description]
 * @return {[type]} [description]
 * @extend
###

Copied from original issue: atom/autoflow#9

I would like to implement this functionality, but I cannot reproduce the example. What I get from reflow selection is like this:
###* * Constructor, options are passed in from the cli tool or manually when
#using nsync as a library. * By default, it just sets schema properties that all
#transports use. * @param {[type]} options [description] * @return {[type]}
#[description] * @extend ##


🐛 --repoter not working with check and lint command when lint from stdin

Environment information
CLI:
  Version:                      1.9.2
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           windows

Environment:
  BIOME_LOG_PATH:               unset
  BIOME_LOG_PREFIX_NAME:        unset
  BIOME_CONFIG_PATH:            unset
  NO_COLOR:                     unset
  TERM:                         unset
  JS_RUNTIME_VERSION:           "v16.20.2"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    true
  VCS disabled:                 true

Workspace:
  Open Documents:               0

What happened?
echo "var a = 123" | npx @biomejs/biome lint --reporter=json --stdin-file-path=test.js

output to stdout
var a = 123
stdin ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  × The contents aren't fixed. Use the `--fix` flag to fix them.

Expected result
--reporter should works
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

Why should reporters work on stdin? That's by design.

I don't know what the purpose of this design is.
But I think the output should be formatted by reporter.
For example, I got a scenario now.
I want to lint a file. But since I have already read the file, I want to pass it in through stdin to save the another file reading.

I didn't understand why a JSON reporter is needed in stdin. I understand you have a use case, but I honestly didn't understand what this use case does.
Also, you expect the --reporter to work, but you didn't explain what you expect to get from the output. At the moment, when you call a command without --write, the stdin mode return the original code.

Is there a particular reason to not make --reporter compatible with stdin + --stdin-file-path?

If we decide to do so, we need to explain to users why we implemented and what's a valid use case. I'm not against implementing stuff, but we need to be good at justifying things so we don't regret them in the future. That's part of our philosophy

we need to explain to users why we implemented and what's a valid use case.

For keeping --reporter consistent. When this flag is specified, all output should be formatted by the reporter, without any exceptions.


model: Expose more information

We know we need to expose the following before stable API release:

[ ] Model type

Classifier, Regressor, Cluster, NLP, etc. Need to enumerate all these we have right now

[ ] Model trained/not-trained status

Boolean value which we need to know before attempted to assess accuracy or prediction

Okay so, I'll talk here about enumerating the types.
From the types mentioned above, one may be a sub-type of the other...
For example, there are nlp and cv models that can be classified under 'classifiers' and vice versa.
They could be classified into:

supervised and unsupervised
classifiers, regressors, and clustering models.
linear models, naive bayes, decision trees, ensemble methods, neural networks, etc.
NLP, CV etc.
and maybe more

Every NLP and CV model out there could be tagged with a type from each of the lists above.
Say, a dog classifier on Pytorch would be a classifier, a CV model, and a neural network model.
The approach really depends on the amount of detail we want to go into.
Also, will we be using this to later filter out models in UI? If yes, we'd want to somehow tag each model in every way we can(having multiple tags) to later have more options for filtering.

Exactly @mHash1m !! We can differentiate between models in a lot of ways and we need to make sure that we're on the same page about this and thus we should definitely pick this up in next weekly sync. Until then I think I can make PR implementing  Model trained/not-trained status as it is pretty simple and there's no confusion around it as well.


Failed to connect to HA

Hi everyone,
i'm trying this plugin but i can't connect with my HA.
MacMini osx10.15.7
Stream Deck Version: 5.1.3 (14750)
HA: Home Assistant OS 2021.12.2
The error I get on Stream Deck is "Failed to connect to ws: //...etc"
while going into the system log of HA I get this error:
2021-12-16 15:09:57 ERROR (MainThread) [aiohttp.server] Unhandled exception
Traceback (most recent call last):
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1183, in _sendfile_fallback
read = await self.run_in_executor(None, file.readinto, view)
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 514, in start
resp, reset = await task
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 460, in _handle_request
reset = await self.finish_response(request, resp, start_time)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_protocol.py", line 613, in finish_response
await prepare_meth(request)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_fileresponse.py", line 286, in prepare
return await self._sendfile(request, fobj, offset, count)
File "/usr/local/lib/python3.9/site-packages/aiohttp/web_fileresponse.py", line 99, in _sendfile
await loop.sendfile(transport, fobj, offset, count)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1162, in sendfile
return await self._sendfile_fallback(transport, file,
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1192, in _sendfile_fallback
await proto.restore()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 263, in restore
self._transport.resume_reading()
File "/usr/local/lib/python3.9/asyncio/sslproto.py", line 343, in resume_reading
self._ssl_protocol._transport.resume_reading()
AttributeError: 'NoneType' object has no attribute 'resume_reading'

UPDATE. I tried to disable the SSL certificate, removing these entries from the config.yaml:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
With the SSL Certificate disabled the Stream Deck plugin works, it connects and I can turn my lights on or off. Unfortunately when I reactivate it it no longer works. Any suggestions?

Hi,
i am using the plugin with Home-Assistant behind an SSL reverse proxy with an "official" LetsEncrypt certificate. So in general, SSL secured connections should work.
StreamDeck is using Chromium as engine for their StreamDeck app. Maybe, if you are using a self signed certificate, chromium does not accept it. In this case, there is no way around it, because I can not change the internal settings of Stream-Deck's chromium engine.
I hope this helps

Hi, I also use a Let’s Encrypt certificate, am I wrong somewhere else?

Hmm, did you prefix your home assistant url with "wss://"?
ws = plain websocket
wss = with ssl

I tried both prefixes, both ws and wss with local address and with dns. Port forwarding is okay.

Sorry, I was busy doing intense real life :)
Unfortunately i have no idea, what could be wrong with your setup.
If you are familiar witth chrome's developers tools, you could try to take a look at the logging / debug information from stream deck plugin: https://developer.elgato.com/documentation/stream-deck/sdk/create-your-own-plugin/#debugging.

I was having same issue because the documentation suggested not specifying a port with SSL but it works after I specified my port which was 8123.
example:
wss://your-address-of-home-assistant.duckdns.org:8123/api/websocket

I will update the documentation to make it more clearly. Thanks for your input!


do not test MPI on Windows with coverage

There are spurious test failures of Trixi.jl with MPI on Windows, see
https://github.com/trixi-framework/Trixi.jl/issues/901
To reduce their impact, we do not test MPI with coverage on Windows.
This reduces the chance to hit a speurious test failure by one half.

We do still run regular MPI tests on Windows, right?

Exactly - I just skipped the Windows MPI tests with coverage - tests without coverage are not affected.


Update README.md

This project aims to achieve the same performance as llm.c and making the resulting code maintainable, e.g., turning the While loops generated from c2rust into For loops, which enables the parallelization through the rayon library.

cool! :)


Support refining overloaded functions without callback annotation

Intersection function types are a great way of preserving type specificity, but it's a pain that callback functions must be annotated for this to work. Flow can often infer the correct type automatically when annotating with the existential type *. It would be nice if this would work without annotating the callback.
// @flow
declare function foo(fn: () => null): null;
declare function foo(fn: () => number): { n: number };
declare function foo(fn: () => number | null): { n: number } | null;

// Works when annotating the callback with the existential type
const a = foo((): * => null);
// Flow errors without annotation
const b = foo(() => null);

Errors with v0.62.0:
8: const b = foo(() => null);
             ^ call of `foo`. Could not decide which case to select
8: const b = foo(() => null);
             ^ intersection type
Case 1 may work:
2: declare function foo(fn: () => null): null;
                       ^ function type
But if it doesn't, case 2 looks promising too:
3: declare function foo(fn: () => number): { n: number };
                       ^ function type
Please provide additional annotation(s) to determine whether case 1 works (or consider merging it with case 2):
8: const b = foo(() => null);
                       ^ return

it now works without annotation


Cannot find module "../index.js"

After installing hardhat-ethernal into a hardhat project and then requiring it in my config, I'm getting the error:
Error: Cannot find module '/Users/Dan/Desktop/repos/hardhat-ethernal-test/node_modules/hardhat-ethernal/dist/src/index.js'. Please verify that the package.json has a valid "main" entry

Looking in the node_modules it doesn't appear to have a /dist folder

Can you try again with version 0.3.2, please? That should fix it!

Worked like a charm! 🙌


[WIP] Purge miq requests every 6 months

We have no process to clear out miq requests.
If we do not want to automatically delete these, I would feel more comfortable putting most of this PR in but removing the scheduler to automatically create them.
I am concerned about MiqRequestTask.where().destroy_all. I remember there was some trick with the tasks that do have child tasks, but can't remember the actual nuance. For this reason, I stuck with destroy. But we are going to bring a lot of records over the wire. MiqApproval is more straight forward and we can use delete_all

I am concerned about MiqRequestTask.where().destroy_all

I wonder if we need to look for the related miq_requests rows associated with the tasks.  If all tasks associated with the request have been removed, we might want to delete that too.  I caution you that I started on this but was stuck because I have no idea how to test this for real other than made up specs.
You can see my similar work, but for queue work that was in flight when a worker was killed, here: https://github.com/ManageIQ/manageiq/pull/21485/files

I am concerned about MiqRequestTask.where().destroy_all

I wonder if we need to look for the related miq_requests rows associated with the tasks. If all tasks associated with the request have been removed, we might want to delete that too. I caution you that I started on this but was stuck because I have no idea how to test this for real other than made up specs.
You can see my similar work, but for queue work that was in flight when a worker was killed, here: #21485 (files)

Note, I'm ok with waiting on that.  I honestly just don't know enough of what the various tables hold and how they're used with each type of thing, provision, services, etc. to say what's right or wrong.

@kbrock did you get a chance to look at https://github.com/ManageIQ/manageiq/pull/21577#issuecomment-982764050 ?  I don't know if we can clean up some of these without getting their associated other requests/tasks.  Maybe it will just work since they will all get purged after 6 months anyway?  I don't know.  Maybe this PR is just simpler.

WIP: I do not know how to detect if this workflow is still running. (per @jrafanie comments) So it is possible that we destroy a long running workflow. Although, a workflow that runs for 6 months is quite long.
Not purging associated records but purging all tasks/requests older than a certain date would work. I just worry that we delete a request that is part of a service template or something. I seem to remember workflows being creative in how they stored the templates.

@jrafanie do we want to merge this with #21485 ?
There was more thought for what records want to be deleted over there
Here I focused on the purging infrastructure.
I think the main thing that needs to be done with this pr is we need to change purged_scope to properly determine which records are able to be removed. (separate from what time frame we want to remove and batching)
We possibly want to change the way associated records need to be purged, but that would be an optimization

outstanding: not sure how to determine which workflows are still running, so can't determine if it is safe to delete a workflow.

update

rebase to fix conflict

Still WIP: just like https://github.com/ManageIQ/manageiq/pull/21485 - tricky to determine whether a workflow is still in use, and therefore don't want to delete a request out from underneath the workflow


replace headers_workaround

This PR aims to fix the headers_workaround kludge:

setup.py now follows closely numpy/scipy setup (should work with distutils and setuptools)
setup.py doesn't import cython anymore (see bin/cythonize.py)
headers for native dependencies (numpy, murmurhash) are now shipped as fallback
add build.sh and tox for CI
adds versioning mechanism (from numpy/scipy)

Building spaCy is now more clearly separated between 1) creating an sdist including cythonizing the source (typically performed by the maintainer) and 2) building/compiling the package (typically performed by the user).
Headers from numpy and murmurhash (copied from sdist build-time environment) are now shipped in the sdist (see package ./include dir) and used during installation in case they couldn't be found on the system.
Note that for creating an sdist or running tox you already need a python environment with all dependencies from requirements.txt, otherwise cython cannot build the sources. Take a look at build.sh for a sample setup.
Overall setup.py behaves now more standard-like: python setup.py develop or pip install -e . should work now. python setup.py build_ext --inplace is now deprecated.
The versioning automation is a leftover from numpy/scipy setup.py, but I thought it might serve as a good starting point. Obviously this part could be easily left out/replaced.
So far only limited testing took place: Mac/Linux 64 bit latest setuptools py27/py34
Sorry, I had to delete some files that were currently not cython-compiling (_nn, _theano, senses) or didn't run (test_de).

Thanks, this is looking really promising!
I'm trying to go over this being super paranoid, so that we can get the installation issues well and truly settled. So, forgive me if some of the comments sound like I'm being difficult :). Just trying to really get this nailed.

Yeah, don't be too eager to merge this, I want to get a full setuptools/disutils version build matrix green on this before I would consider this stable.

Should this be merged now?
Even if it's not perfect, it looks to me like it's already an improvement over the previous kludge. Do you have any outstanding TODOs or tests for it?

I am currently testing across some non-Linux platforms, but I already feel pretty confident about this branch.

Added a new build wrapper, mostly needed for CI systems, but one can also run it locally, e.g., for testing a standard setup via pip:
python build.py prepare
python build.py pip
python build.py test

or using an pip/setuptools from January and running "python setup.py install" on it:
python build.py prepare 2015-01-01
python build.py setup-install
python build.py test

Additionally, one can call it wrapped in a virtualenv on win/linux/mac - might still need a little sync on the parameter handling between powershell and bash script:
venv.ps1 -python c:\python27\python.exe -install_mode pip -pip_date 2015-01-01
venv.sh /usr/bin/python2.7 pip 2015-01-01

This looks really great. Should I do some final checks tonight, and (likely!) merge?

Sounds good, also I'd like to get all CIs green.


PlayStore entries and app updates

I´d like to use this issue to discuss what could, should and will happen with the PlayStore Entries like mentioned in #736 and #763.
The decision is: Updating the old app or releasing a new one.
To update the old app we'd need access to the signing-keystore and to the google play developer console. This option would be the easiest for the users, but we need the permission from GitHub (as discussed in #771).
When releasing a new app, we would have to find a new name for the developer/pubisher and maybe even a new name for the whole app (for the last point see #771).
Even if we don´t get access to the keystore and playStore developer console and are forced to use the second option it'd be great to publish one last update for the old app replacing the actual app with a hint about the new app

To update the old app we'd need access to the signing-keystore and to the google play developer console

Yeah, I don't think giving out access to the keystore is something that can happen.

In this case we're forced to publish a new app under a new name (with a new keystore).
@kevinsawicki What's your opinion on my last suggestion? One last update for the users of the old app which just contains a single activity with a hint like "This app is not longer maintained. The new Version can be found here: "

One last update for the users of the old app which just contains a single activity with a hint like "This app is not longer maintained. The new Version can be found here: "

Yeah, I think this is a good idea and something worth doing :+1:

Thanks @kevinsawicki
But we should wait with this until the first version of the new app is published

Should i provide this 'dummy' app?
in an extra branch? or extra repository?

But we should wait with this until the first version of the new app is published

Yeah, I think this makes sense.

Should i provide this 'dummy' app?

Maybe just as dialog in the existing app that shows at launch?

This would be possible, but it in this case the new app has to be based on the 1 year old 1.9.0 release
Furthermore you have removed the app from google play which means in my opinion that you don't want the old app to be used anymore and 'just a dialog' wouldn't make the app unusable

Since the discussion in this Issue if flowing beautifully, let me add two questions:

What happened to the old app? I have seen that @fadils forked it and basically saved its life.
Would you please add this link to your app description just like here?

I'm finalizing everything to upload the app to the appstore.
It's still based on 1.9.0.

Just to understand, the version that @fadils is releasing is going to be the unofficial successor to the official app? or just a redirect to somewhere else?

Come on guys. Update your readme on what you are working and what if planned. Write down why it isn't 'official' from github anymore and closed the one hundred issues about that subject...

@StefMa we're sifting through outstanding pull requests and issues. We have full time jobs and it's not something we should rush through.

@StefMa When the planning (what this issue is made for) is finished, we will update the README accordingly.
But for now, we are waiting for @fadils answer to @M-Zuber's question

Been talking with @fadils about this privately
My proposal for a general roadmap (with no ETAs) though is this:

We don't rush something out the door. We need to get to a stable base, and then maybe shoot for the initial release of the public project as a 0.1.0 release. From a stability standpoint, we should try to get our open issue count back down to 0, and then move from there.

Formalized structure for new app. Organization, releases, new app name, etc. My suggestions for the hat are:

App Name: Octo
Play Store Publisher: Forkhubs

Get everyone on the same page. There's one or two forks out there that are maintaining parallel development, and this just fragments the process. People don't know what to contribute to. Now that we have a formal successor, we should get everyone onboard with this so that there's no confusion about where someone should contribute to. We should also start bringing in the improvements/fixes from those forks back to this project. We should also stop referring people to them, either in pull requests/issues or as an alternative, again because it just fragments the process. What's more annoying is one or two of these forks I've seen on the play store claim credit for changes they didn't make. (@jonan you're not one of them, just to be clear :smiley:)

We have a single updated version of the original app for one final release, that just shows a dialog saying the project has migrated to this and include a link to the new play store link. We would launch this at the same time as the new one. @kevinsawicki please let us know what you think of this.

Proper crash reporting. Not sure what's in place or accessible right now, but Bugsnag is great and free for open source projects (as long as we give them a public shoutout in the README or somewhere). This way collaborators on the project can have access to this and triage crashers from it.

Finish the visual refresh. We started this in December, and have come a long way as far as getting a nice material design look. This plus stability can be the main feature point of a 2.0 release. There's still a few outstanding areas we can improve here:

List items UI (maybe borrow a little from u2020's new look)
Material dialogs (I see it's added, but I don't see them in the actual app yet). Preferably using the new AppCompat versions.
Text input fields. They're currently very boxy. I get that this was originally to match the Github website UI, but I think this project should take advantage of its new flexibility and move in a more material and conventional android direction.

Getting a stable release out the door would be a massive first step. After that we can start to work on new features. For now I think stability, the UI refresh, and migration should be the major platforms for the first release. We can consider doing a beta on the play store first as well.

@hzsweers For number 4 look at this comment by @kevinsawicki: https://github.com/forkhubs/android/issues/772#issuecomment-93604590

Oops, must've missed that. Good to know

Agree to whatever @hzsweers mentions above..

Thanks for the update. Sounds great. I am very much so looking forwards ti going back to a native app.

@hzsweers, thank you for publishing the master plan, it feels good to eyeball all this and learn stuff for my own projects. General question directed to you: How come you chose Bugsnag instead of CoverityScan or Fabric? Would someone, possibly even @fadils, be so friendly to clarify what happened to the original GitHub Anddroid app? How come the whole project even has to move? I don't get the story..

GitHub has moved the project to a new home, and will no longer be maintaining it. Instead, it will now be a community-developed project. We're currently working on preparing it for an initial stable release (that is, not much different than the last official store app functionally. A UI refresh, squashed bugs since, and migration from the original app). After that, we will begin new feature work.
I like Bugsnag because it's simple and has a no-BS approach to error tracking. Both Fabric and CoverityScan's websites make me want to gauge my eyes out. I've used Bugsnag, Crashlytics, and HockeyApp, and found Bugsnag to be the cleanest/most practical solution by far.
I checked them out after a glowing review from Jake Wharton from Square (he/they use them as well). Here's a link to that for a more in-depth look at Bugsnag: http://www.reddit.com/r/androiddev/comments/2sw11m/anyone_used_bugsnag/

Thanks for sharing the background, @hzsweers! Will discuss using Bugsnag with my team now.

@hzsweers said, "Instead, it will now be a community-developed project." So is there a public URL for this?
Is "ForkHub for GitHub" by Jon Ander Peñalba the so-called community version?
https://play.google.com/store/apps/details?id=jp.forkhub
Please kindly clarify which app at the Google Play Store is most legitimate, since GitHub removed the official version. Thanks.

No. ForkHub is not the community version. It's a fork maintained by @jonan that was originally started due to the lack of maintenance here. It is my hope that he will stop maintaining it and referring issues here to that now that this is ramping up again, and help us focus on this project again. For better or worse, the organization name chosen when GitHub relinquished this project is just very similar. I can definitely understand the confusion.
There is no "legitimate" app on the play store by any legal standards. This app will be no different. The app in this repo is not on the play store, yet. It will be once we release it. We are focusing on getting it to a solid foundation, finishing the UI refresh we started, and clearing/triaging the outstanding issues and PRs that have accumulated. There is no time table for this, it will be done when it's done.

I don't think there is a "legitim" app.
Apps ending in "hub" are forks:
ForksHub
ModernHub
And other aren't:
GitSkarios
OctoDroid
Please, don't use the term "legit" since GitHub removed their own app
That's the game of thrones... sorry, apps

That's coincidence, but not a formal naming convention.
So yes, as I already said

There is no "legitimate" app on the play store by any legal standards. This app will be no different.

Yes i know it's coincidence, it's just all ".hub" apps are forks :)

Please, don't use the term "legit" since GitHub removed their own app

I still don't get why @GitHub removed their own app! It just doesn't want to stick in my mind...

I'd actaully enjoy if @GitHub or @forkhubs would ditch Google like our AIMSICD does here. :+1:

That's not happening.
On Wed, Jul 8, 2015 at 9:07 AM Security: Pwned<EMAIL_ADDRESS>wrote:

I'd actaully enjoy if @GitHub https://github.com/GitHub or @forkhubs
https://github.com/forkhubs would ditch Google like our AIMSICD
https://secupwn.github.io/Android-IMSI-Catcher-Detector/ does here
https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/wiki/FAQ#q-why-wont-you-upload-your-app-to-the-google-play-store.
[image: :+1:]
—
Reply to this email directly or view it on GitHub
https://github.com/forkhubs/android/issues/772#issuecomment-119637406.

That's not happening.

Then at the very least, please also officially distribute your app via

Why? People can just build from source or download APKs from the releases
section when we start releasing.
On Wed, Jul 8, 2015, 9:06 PM Security: Pwned<EMAIL_ADDRESS>wrote:

That's not happening.
Then at the very least, please also officially distribute your app via [image:
F-Droid] https://f-droid.org/
—
Reply to this email directly or view it on GitHub
https://github.com/forkhubs/android/issues/772#issuecomment-119809067.

Why? People can just build from source or download APKs from the releases section when we start releasing.

I like that you'll provide the direct download of the APK in your releases. However, some people may find it a good idea being automatically notified when an update is available. I see no reason to avoid F-Droid.

I do, simply because F-Droid's cult following constantly nagging developers to upload apps to another distribution system rubs me the wrong way, and I'm not interested in condoning it.

-closely paying attention-
:smile:

-closely paying attention-

Waiting for the bitch-fight? ;-) No, I respect @hzsweers choice, but could also offer to set it up for you.

Hello,

@hzsweers wrote in https://github.com/forkhubs/android/issues/772#issuecomment-97620340:
No. ForkHub is not the community version. It's a fork maintained by @jonan that was originally started due to the lack of maintenance here. It is my hope that he will stop maintaining it and referring issues here to that now that this is ramping up again, and help us focus on this project again.

I read the following comment from @jonan :

@jonan wrote in https://github.com/jonan/ForkHub/issues/15#issuecomment-99229049:
There is no longer an official app, GitHub has removed it from the Play Store and moved the repository to https://github.com/forkhubs/android. That repo and this one are improving the old app taking different paths.

Does that mean that you are not working together and that there will be two different apps now?
Regards

I guess. I called on forkers an an earlier comment here to focus on this repo now that it's a public project, but never got a response from him specifically. This repo is the original repo though, and for all intents and purposes will be the spiritual successor to the original.

I called on forkers an an earlier comment here to focus on this repo now that it's a public project, but never got a response from him specifically.

Uncool. It would be much better if @jonan was so kind so send an answer to @hzsweers, so that you guys really do not move apart, but make a unifioed effort to craft one awesome app. Please try again!

This thread has become sidetracked, so I'm closing it. We have a plan, and will be proceeding with it. Please see the README for further updates.

I recommend you to lock the issue too, if not people will comments and
reopen it
On Sun, Jul 12, 2015, 14:18 Henri (Zac) Sweers<EMAIL_ADDRESS>wrote:

Closed #772 https://github.com/forkhubs/android/issues/772.
—
Reply to this email directly or view it on GitHub
https://github.com/forkhubs/android/issues/772#event-353767993.

Good point, done.


Update TAG landing page to represent o11y projects outlined in https://cncf.landscape2.io/

Section at https://github.com/cncf/tag-observability?tab=readme-ov-file#cncf-projects-related-to-the-tag needs to be updated to represent latest projects and status as outlined in cncf.landscape2.io

See related PR https://github.com/cncf/tag-observability/pull/191

Completed. Closing issue.


DEVEXP-382: Conversation API - Change package exports

Yes, and thanks (again!) for your comments, I didn't find it useful when I wrote the first version of the code, but I'm convinced it's a great addition for the developer experience to access the helpers under a dedicated namespace. It's far easier to find.


apex dev runs a serverless app locally

This is an idea for a new feature.
Context
Running your serverless app locally, and in a fast and repetitive way is key
for development productivity.
However being tied to AWS Lambda environment makes it challenging as the app
relies on proprietary services such as the API Gateway, the Lambda runtime
libraries and (the Lambda service itself).
While it's not possible to entirely replicate the Production environment, it's
possible to emulate a local environment close to Production.
Proposal
A new command apex dev spawns a local environment that the user can hit for
testing the app without deploying it to AWS Lambda.
Once you run apex dev, apex builds the app into a container (the container
image contains both the result of apex build and the same runtime than AWS
Lambda. After the containers are created and running, the CLI blocks on the
app logs (similar output than apex logs -f).
Once the user interrupts the CLI (SIGINT), the containers are stopped.
Implementation
This is not exhaustive, just ideas on how to implement and what dependency can
be leveraged.
Container runtime
Docker for Desktop (Mac or Windows)
can be the containers runtime, it has the advantage of having an easy
installer, is actively and maintained and support upgrades.
It's important the the container image itself is similar to the environment
used on production. docker-lambda is a public container image
which is actively maintained. It is built from the real AWS Lambda environment
and can be used as a base image to build the dev app.
The first the user runs apex dev, the command will check that dependencies
are satisfied (container runtime up and running, container images pulled, apex
build hook is configured).
API Gateway
It's important to have an easy way to configure the API gateway, in the same
way the user would do it on the AWS Gateway service.
The API server can be configured from a YAML file named api-dev.yml, that
should be place in the root directory.
Example:
/api/hello:
    method: GET
    function: hello

When the user runs apex dev, apex (or an apex build hook) parses the Yaml
file and generates a corresponding nginx configuration.
An nginx container is then spawned on the local container runtime with the
above generated config.
For trying the local app, all connections should be directed to the API Gateway
container.
Possible future improvements

IDE integration
Emulate IAM role configuration and enforcement
Web UI for configuring the API Server and introspect the functions

I personally only use API Gateway with a single function (per api, not per endpoint), and I use a regular Go net/http server so local testing isn't an issue there.
I think even if someone where to contribute this as a feature I'd have to respectfully decline, just because it would be a large maintenance burden, and I'm effectively the only dev now. Given time and money I'd agree though!
cheers


add completion for ctr

Usage: add source <(ctr completion bash) to ~/.bash_profile.
Similar to kubectl completion bash.
Fixes: #7147
Signed-off-by: zhaojizhuang<EMAIL_ADDRESS>

@kzys

Please sign your commit for DCO.
https://github.com/apps/dco
(run git commit -a -s --amend, and make sure that the Signed-off-by: NAME <EMAIL> line with your real name is included in the commit message)

@junnplus done

@crosbymichael @Random-Liu

friendly ping @dmcgowan

Since you opened this PR we fixed a problem with our Cirrus CI configuration; to get a clean CI run you need to rebase on main HEAD commit.

Vagrant BOX:rockylinux/8 failed, anyone know？ @estesp @dmcgowan @crosbymichael

What's difference with https://github.com/containerd/containerd/tree/main/contrib/autocomplete
Can we avoid two difference completions? If a subcommand is easier for user to use, then remove the static file, and update the documents https://github.com/containerd/containerd#enabling-command-auto-completion

What's difference with https://github.com/containerd/containerd/tree/main/contrib/autocomplete
Can we avoid two difference completions? If a subcommand is easier for user to use, then remove the static file, and update the documents https://github.com/containerd/containerd#enabling-command-auto-completion

@zhsj
Two reasons:

The way in https://github.com/containerd/containerd/tree/main/contrib/autocomplete  requires the user to download and save the shell script. While a subcommand  is easier to use just in the way as follows:

source <(ctr completion bash)
echo "source <(ctr completion bash)" >> ~/.bashrc

In the future, we can also add more extended functions, such as after ctr c, we can associate a list of possible containers by querying the list of containers via containerd SDK

In the future, we can also add more extended functions, such as after ctr c, we can associate a list of possible containers by querying the list of containers via containerd SDK

Isn't it already possible if the command implements https://pkg.go.dev/github.com/urfave/cli#BashCompleteFunc ?

Can we avoid two difference completions? If a subcommand is easier for user to use, then remove the static file, and update the documents https://github.com/containerd/containerd#enabling-command-auto-completion

Agreed on having one method to do completions. Easier may be subjective there since it maybe easier to have a separate autocomplete script if you are installing from a package. If you are downloading the binaries, just adding a line to local rc file is easier. @zhsj could those scripts be updated to use the same autocomplete function so packagers can have the separate file while still having a consistent autocomplete?

could those scripts be updated to use the same autocomplete function so packagers can have the separate file while still having a consistent autocomplete?

For urfave/cli, the bash/zsh completion files are static. It doesn't need to be generated dynamically. urfave/cli achieves this with the builtin --generate-bash-completion option. It seems only fish completions needs to use https://pkg.go.dev/github.com/urfave/cli#App.ToFishCompletion
Otherwise we can't benefit from https://pkg.go.dev/github.com/urfave/cli#BashCompleteFunc
How about using go:embed to embed the static bash/zsh completions in ctr and then let ctr completion to print them?

Hi, i'm on AlmaLinux or ReHat, i have kubectl completion bash, crictl completion bash, but i haven't ctr completion bash, it is related to this topic? someone can help me about ctr completion bash ?


Implement 3 instances of blade in OpenTurbine

Blade will be defined blade coordinate system and that instance must be copied to the initial orientation and position for the three blades at t = 0.

Currently writing a vtk script.
Has not started creating multiple instances of blades.  Will pause on vtk script to focus on the creating three blades.

Working on two instances of the blades.  Should be ready for review today.  Short discussion on data structure numbering -- e.g., numbering bodies and then elements/nodes within bodies vs. just elements and nodes

Added logic for assembling linearization matrices. Need to implement constraint gradient code.

Implemented and running but linear system solver is having an issue. Likely something in the assembly.

found error in iteration matrix and has plan to fix -- will test this morning.

There is a test case in place.