Selecting the scope for the client in DI

Add options to change DI lifetime for NClient.

general Add.. methos now has optional parameter ServiceLifeTime (singleton by default)
Many new extensions like Add...Singleton(), Add...Transient(), etc.

@smolchanovsky

Great job! But the test coverage is confusing: 37.0% Coverage

Great job! But the test coverage is confusing: 37.0% Coverage

So... which type of test do you want? There are only method overloads without any logic. I'm open to any offers

Great job! But the test coverage is confusing: 37.0% Coverage

So... which type of test do you want? There are only method overloads without any logic. I'm open to any offers

I agree with you, logic is pretty simple, but we should have tests to protect us from typos. For example, method must create singleton instance, but creates scoped

So.. Is it enough now?

Great job! But the test coverage is confusing: 37.0% Coverage

So... which type of test do you want? There are only method overloads without any logic. I'm open to any offers

I agree with you, logic is pretty simple, but we should have tests to protect us from typos. For example, method must create singleton instance, but creates scoped

so.. is it enough now?


error generating images after upgrading from v0.6.0-pre to v0.6.1

When upgrading from one of the v0.6.0 pre-release versions to the v0.6.1 release, the new face outscale slider may not be set correctly, leading to a type error when sending the image request:
TypeError: Cannot read properties of undefined (reading 'toFixed')
    at appendUpscaleToURL (main.js:39132:68)
    at Object.txt2img (main.js:39197:11)
    at Object.generateImage [as mutationFn] (main.js:65986:35)
    at Object.fn (main.js:37436:33)
    at run (main.js:36694:33)
    at new Retryer (main.js:36739:5)
    at Mutation2.executeMutation (main.js:37431:22)
    at main.js:37399:22

Since the state version changed between v0.5.0 and v0.6.0, that should erase existing/invalid state when upgrading from v0.5.0, and I think this is only an issue when coming from one of the v0.6.0 pre-release builds.
Clearing the app data should work, as usual.

I don't think this is happening when upgrading from v0.5.0 to v0.6.0, so I'm probably not going to add a migration unless that's also reported, but I have added a Reset All button to the client that will reset your local state. That will erase any prompts and parameters you have saved, but it should fix this error and similar ones.


add js with greeding information

Great start! there is still the servlet code missing and you website is erroring out when trying to reach that endpoint "page-views" endpoint.


Type Guide either in the Documentation or in a readme file.

Description of proposed feature

There should be a clear type guide for which types to prefer in manim. There are a lot of ways to type things for example Optional[int] and int | None are the same thing when considering a linter like mypy, but they convey a different story when reading. For parameters if something has the type Optional it's very clear that this parameter can be left out safely and the rest is handled by the function itself.
This also reflects itself inside the function when reading the typehints, where the error messages state that the type is Optional and thus things like x.something don't work. This is also the case with int | None (it translates to Union[int, None] but it suggests that this variable can be in general a None value and also might just be changed back to one during the lifetime of the Object.
That's why i think we need to discuss a clear typeguide for manim and also have some kind of suggestions and help regarding typing.
I also would suggest the addition of a type module for Custom types needed in the future like the Color type which currently is str | Color, but this might be an addition for another day. But could also be discussed here if we need some standard types.
Related to

#52

It would be very nice to have a dedicated manim.typing module where we can (consistently) write more complicated types and then just use them in the rest of the library.
In terms of the semantics between Optional[bla] vs. bla | None: do you have any references for how other projects handle this? Personally, I don't have a strong opinion on caring about semantics between the two variants.


DF-484:update-project-guidelines

Related ticket(s):
https://national-archives.atlassian.net/browse/DF-484
About these changes
Document guideline changes
How to check these changes
Process to follow
Before assigning to reviewer, please make sure you have

[x] Checked things thoroughly myself before handing over to reviewer.
[x] Included the ticket number in the PR title to help us keep track of changes.
[x] Ensured that PR includes only commits relevant to the ticket.
[x] Waited for all CI jobs to pass before requesting a review.
[x] Added/updated tests and documentation where relevant.

For Reviewer
Once PR is merged, check and arrange to deploy on platform-sh.

approving, these are useful updates


Move out the command parser to TDSM

Command parser is fully moved out to TDSM, excluding ISender stuff (still deciding the direction im heading with that as it could be of some use if Terraria.Entity isn't - up for discussion)


Breaking API change in Querydsl 4.3.0's APT module: constructor parameter of DefaultConfiguration changed

This commit incompatibly changed the constructor of DefaultConfiguration so that existing code will neither compile correctly against that class nor can use the class in Querydsl 4.3 at runtime. This prevents Spring Data MongoDB and its users from upgrading to that version.
Would you mind re-introducing the former constructor variant?

We can add an alias for the old constructor indeed.
But I don't get why you would need the APT classes on runtime?

By the way, if shipping your own APT plugin, you must be happy to have access to the ProcessingEnvironment through the module now and might want to consider to require Querydsl >= 4.3.0. Or did you find any other means of obtaining the ProcessingEnvironment?

@jwgmeligmeyling
see
https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/repository/support/MongoAnnotationProcessor.java

Yes we do, as we need to make the Querydsl APT pick up classes with a Spring Data specific annotation (@Document) and also flip a default in configuration (see MongoAnnotationProcessor).
My Point being: breaking API changes are a big nono if you want to make sure people really use a library. I can raise the dependency version to 4.3 for Spring Data MongoDB but with that, I am forcing all users to upgrade, which might have unanticipated side effects that I cannot forsee and people are not used to that when they upgrade to a new minor version of a Spring library. They might be able or even need to downgrade to a Querydsl 4.2.x but all of this is stuff we somehow need to communicate and I'd like to avoid that. I don't want to start mixing different versions in terms of "that's what we use to compile our APT", "that's what we recommend to use at runtime etc.".
Are you actually publishing CI snapshots again? We used to point to the snapshots of upcoming versions and run our CI against those to catch stuff like that as early as possible. With the development here taking up some pace again it might make sense to revive that practice.

I understand your point. I am not sure whether the APT module was ever considered an API, but apparently it's used as such and I am personally interested in making the APT more extensible as well. So don't get me wrong, I absolutely encourage the existence of the MongoAnnotationProcessor.
The change mentioned by the way will make it possible for ServerProviders to hook onto the APT process and bind custom types that need the ProcessingEnvironment. Therefore QueryDSL can be extended with for example custom expression types for custom types, without needing yet another AbstractAnnotationProcessor subclass.
It doesn't seem like a lot of trouble  to add a constructor alias and maintain binary compatibility, so I'll create a PR for that. I am not sure what the schedule will be though for releasing it. The team still seems pretty much in startup phase. There's lots of abandoned PRs and issues here still.
In the mean time you might want to do a constructor lookup with reflection for either scenario. The parameters for either of the signatures are readily available at your point of construction.

@odrotbohm Thanks for bringing this to our attention. We'll restore compatibility ASAP and be sure to keep these considerations in mind in the future.
We still release snapshots, so this makes a lot of sense.
@jwgmeligmeyling The PR has been reviewed. The release process has undergone a major facelift, but it is not yet fully automated. As such, it might take a few days to be published.

Thanks for the fast responses everyone! Is there a rough ETA on 4.3.1? We have an RC coming up March 31st and wonder whether we could wait to just upgrade to that?

@odrotbohm Just released 4.3.1 thanks to @johnktims. Note that we also published 4.3.2-SNAPSHOT, and will continue to do so automatically on merges to master.

Lovely, folks. Thanks again for reacting so fast. We shipped the latest Spring Data releases with upgrades to 4.3.1.


I want to abort the request and show message for user when the parameters is incorrect, How can I do?

In my project, the all request have the same parameters（eg: key and consId）, I want to put those parameters in var parameters: [String: Any]?, but abort the request and push some alert view when the key and consId is empty.

Hey @shuijinliuxi, can you test if the parameters are valid before making the request? Something like:
if (parameterAreValid(key, id: consId) {
  provider.request ... // Make request here
}
else {
  //show alert
}

@pedrovereza  I am doing this at the moment, tks.