Reduce number of dependencies prior to v3

We would like to reduce the number of dependencies prior to version 3 to only the bare minimum required to run an MVC application — without all the bells and whistles. The majority of the components listed in the service configuration of the component are "opt-in", but due to being listed, become hard requirements for end-users.
As such, we need to determine how we can:

conditionally add components (solved via Composer)
wire factories from those components into the application configuration when installed
wire plugin managers from those components into the ServiceListener when installed

Any ideas towards these ends would be tremendously helpful!
Additionally, we need to determine which components are core to the MVC; feedback welcomed!

I was thinking in create different metapackages for different use scenarios.

@Maks3w That's fine. That's not what I'm asking, though. :smile:
I'm trying to determine which components we'll mark as required dependencies of zend-mvc, and how other components, when installed, can notify the application of their factories and plugin managers. Let's keep discussion to those two items, please.

which components we'll mark as required dependencies of zend-mvc

For what use case scenario? As I proposed we should consider different scenarios and provide different sets of required packages for those (metapackages)

how other components, when installed, can notify the application of their factories and plugin managers

This should be discussed out of this specific MVC thread.
Is this the same issue zend-expressive has?
Probably we should turn those metapackages into ZF2 Modules and wire those configs with the standard module bootstrap.

Another option could be write a custom Composer installer and write a single file in some place with the config.

In my opinion the MVC must work without ModuleManager..
MVC + ModuleManager is a perfect feature but it is not necessary for a MVC.. :) but it is only a my opinion.
And a lot of dependencies (loaded by ServiceListener) could be modules that you can choice to use or not..

Zend\Log
Zend\Cache
Zend\Session
Zend\Authentication

which components we'll mark as required dependencies of zend-mvc

For what use case scenario? As I proposed we should consider different scenarios and provide different sets of required packages for those scenarios (metapackages)

This issue is on the zend-mvc repository. I'm talking specifically about the bare minimum required to write an MVC application. When we start talking about usage scenarios, we're talking more along the lines of skeleton packages or meta-distributions — and that belongs in a discussion on the main framework repository (linked). Any discussion of metapackages or installers belongs there. The discussion in here is around the the requirements for the MVC component specifically.

In my ideal world, MVC would just require:

EventManager
ServiceManager
ModuleManager
View

(Assuming Router is still part of Mvc, otherwise also Router!)
i.e. what I see as a ZF-Mvc apps is one that uses modules and a view. i.e. a version of skeleton without the i18n bits.

I disagree about move metapackages to parent discussion. optional dependencies are defined in each component composer so each component has a set of scenarios

@gianarb The plan for v3 is to keep as much BC as possible. Currently, the MVC and ModuleManager have a symbiotic relationship, and we do not plan to change that. You are correct, however, in noting the current components that we might want to start removing as dependencies here: log, authentication, etc. are definitely candidates for removal!

@Maks3w

I disagree about move metapackages to parent discussion. optional dependencies are defined in each component composer so each component has a set of scenarios

I've provided scope to ensure that the thread does not become unwieldy and present too many ideas/options/directions, in large part to reduce the BC risk and amount of development time required to implement. Please respect this.

As noted in the thread on zendframework/zf2#7646: One option for the wiring issues is to make the various components that need to provide factories and/or plugin managers act as modules; this could be as simple as adding a Module class to each one, and registering it with the application.

Agreed with akrabat, those listed are bare minimum and is the starting point for any application. Beyond that, I always tend to do further independent research of whether to use ZF lib for specific functionality (most often yes) or introduce external lib.
I am concerned a little with View. It in itself has a lot of dependencies. Thinking of Renderer and its plugins with strategies.

I like the idea of a Module.php. It's a standardised way that everyone else uses in order to integrate in with SM/EM.

In my opinion a possibile design is

component is a package "framework agnostic" (it uses other components to provide features)
Zend\Mvc supports Module (ok @weierophinney I understand your position, module manager is not divisible)
components are integrable into the MVC as modules.. because we has a ModuleManager!!

The follow is

You could be use module-manager in zend-expressive to serve a module loader.. :) But this is only a dream..

You could only go so far making everything "framework agnostic". For the most part it is a great concept. But can get difficult where components do not seem to work well together. Advantage of monolithic frameworks like ZF2 is everything works really nicely together very seamlesly. Micro-frameworks require too much bridging and clashes of different interface code styles.

@alextech the skeleton application is a monolithic IMO.. The single components have problems but work.. :)

@gianarb yes so I think taking what current skeleton application has, for the most part, is a good bare minimum dependency.  This will also make documentation efforts easier giving a clear line where to start not causing more docs confusion.

I agree with @akrabat the list of dependencies is perfect.. :)
@alextech docs is a required efforts but it can not decide the quality of our code.
@weierophinney a lot of time ago I tried to remove Zend\Log from MVC and move it in a module, maybe we could be "transparent".. I can try to resume my test.

@Maks3w custom installer seems almost like the only reasonable solution. But that's another tool to deal with.  Adding through composer is half a step.  If its a Module, still need to add it to a list of loaded modules manually. Or maybe have the autoloader also detect components in Zend\Modules namespace or whatever appropriate making them automatically available when attempt to use and configure as stated in second point of original message.

First Module can specify another modules which should be bootstraped too.

Another way of looking at it is that:

The dependencies of zend-mvc are the minimum required in order to dispatch the URL /hello and return the words "Hello world" to the client when these words are stored in the Application module's view/application/index/hello.phtml file

Any other component that needs to register with the MVC should do so the same way as any other user-land component: Module.php. It would be lovely to leverage Composer's installation hooks on the other components, such as zend-form, to automatically update application.config.php with the new module.

+1 for Composer Installation hook.  How would take care of potential merge issues with custom configs?

No idea, but Apigility seems to cope…

@alextech We should be able to automate injecting the modules into the application configuration using a composer installer script; working on the Expressive installer has given me a ton of ideas around this. :smile:

Compiled config is only for compile factories. Rest of config and app configs are merged in a 2nd step

How would take care of potential merge issues with custom configs?

Configuration merging happens at the application level, so this isn't an issue. I'd argue any component modules should be added at the top of the module stack, to allow easy overrides via application modules.

I'd argue any component modules should be added at the top of the module stack, to allow easy overrides via application modules.

Agreed.

Perfect!
The tool to manage installation is secondary :)
We must move on the dependencies :)
I don't know if this tool is needed.. We can add a chapter into the docs

Install LogModule to add this feature

2015-11-25 20:31 GMT+00:00 Rob Allen<EMAIL_ADDRESS>
I'd argue any component modules should be added at the top of the module
stack, to allow easy overrides via application modules.
Agreed.
—
Reply to this email directly or view it on GitHub
https://github.com/zendframework/zend-mvc/issues/46#issuecomment-159724351
.

--
Gianluca Arbezzano
www.gianarb.it

Agreed too. Other package managers like Maven has ability to specify module configs as part of the dependency list. Since Composer does not have this @weierophinney idea is great.

If I correctly understand the proposal with which the majority of participants in this thread agrees, action of making all the other components MVC-aware would require changes in each of them. To some extent, that is not in accordance with @weierophinney 's notice:

reduce the BC risk and amount of development time required to implement.

If I may suggest, an interim solution could be creation of a new, specialized component, for example zend-mvc-glue (there's probably a better name), offered through a Composer suggest property, which will wire all the other components with zend-mvc, namely those listed in the Zend\Mvc\Service\ServiceListenerFactory and Zend\Mvc\Service namespace in general.

@nikolaposa Adding Module classes to the various components would not require a ton of work; I think we could do that in parallel to a solution like you're suggesting (which I agree would be expedient, and solve a lot of the BC concerns).

I second @akrabat's definition of the MVC requirements...anything that doesn't directly contribute to processing the request, routing, dispatching, rendering and sending is an "add-on" and should be an optional, separate install.  :+1: on using Module.php in components as well...it's the standard we made so we should dogfood it :stuck_out_tongue:
The only caveat I see to having composer install unshift the component namespace onto the modules list is the way that's usually done: by includeing the config file, doing an operation, and var_exporting it back out to a file.  This will strip everything from the application.config.php file other than the array that is being returned.  That behaviour is fine for Apigility and Expressive, as they had it from the beginning, but doing that in MVC could break some applications (admittedly a very small number); I've seen some "interesting" things done inside that config file (like replicating ZF1's APPLICATION_ENV functionality).

I think that @akrabat has the right idea about the MVC requirements. I also think that using Modules for wiring up additional components to be a good solution. (Not sure how the ModuleManager critics will take this, but the full MVC stack has always required ModuleManager)
One thing that would need to be taken into account with a custom Composer installation script is that there is not always a single application.config.php in use. Apigility as an example splits modules into the separate modules.config.php file and ZF\DevelopmentMode supports the pattern of the optional development.config.php file. (both patterns I personally like and will use more in the future) (I have also noticed console.config.php and http.config.php in a project I have recently joined, where those come from I am not too sure :D)

Please don't do anything that will lead to includeing and var_exporting config files that are not always 100% autogenerated.
@akrabat Why is EventManager a requirement for a bare minimum MVC application in your opinion? I agree to the other suggested requirements.

@hoppithek the MVC system requires it! e.g. dispatching of the controller is done in a listener…

MVC is all around the MvcEvent

@akrabat that is how it is currently done, yes, but I thought we are discussing what the bare minimum for MVC would be. Probably EventManager cannot be left out because of its use in the current MVC stack  just  as ModuleManager will be in, but I don't see a real requirement for it in a bare minimum MVC.

@hoppithek No. We're discussion the bare minimum set of components that need to be in the require section of composer.json.
Related to this, we're also discussing how to integrate any component that wants to register things with the MVC system when it's no longer in this list.

@hoppithek We are discussing the minimum to implement the Zend\MVC, not some "ideal" MVC stack that doesn’t exist yet.
Regarding the config files composer script thingy, I have been kicking around an idea of how the composer install script could work.
Something similar to Expressive installer, but instead of giving you options of packages, it gives you options of what config file you want to inject the module line into.
So depending on what it detects, you might get a prompt similar to this:

$ composer require zend\log
Please select which config file you wish to inject 'Zend\Log' into:
[0] Do not inject
[1] config/application.config.php
[2] config/modules.config.php
[3] config/http.config.php
[4] config/console.config.php
Enter your choice [0]:

@weierophinney Unless you already have coded something up, I would be happy to start prototyping an installation script?

Maybe it is clear to all of you that the EventManager needs to be part, it was not for me. I don't see why MVC should not be able to run without the EventManager but use it when it is available. Yes MVC currently relies completely on the EventManager, but if we plugin other components as needed and provide meta packages or Modules with "glue" effect (as proposed in this thread), to bind it all together the same might work for the EventManager. Since this is a different approach it is probably outside the scope of this discussion when we take all components as fixed and just see what needs to be there to get a running MVC. I also have no personal squabble with the EventManger, so I am happy to have it on board.

I think we should enumerate the scenarios where the MVC component will be used.
For a ZF3 app EM could be required as part of the parent composer and not here.

@hoppithek  EventMenager is core component that is necessary to make many further plugins on top of MVC to work with it. Looking at how almost any other plugin and library in Zend works, many get hooked in one way or another through some event.  Most predominant ones are Router and Renderer.
There is also a concept of application life cycle management. Take a look at table at http://framework.zend.com/manual/current/en/modules/zend.mvc.mvc-event.html These are fundamental concepts of Zend MVC that
(1) won't make it Zend anymore without it,
(2) will make additional components difficult to include beyond this core component
(3) make usage of even this core component alone difficult to impossible without leveraging life cycle events. Many things from identity management in session, authentication, to just basic error handling will break. Every basic MVC stack has that in one form or another.
Your concern with config management is valid.  Concerning configuration files, I actually write them in XML, and then in Module.php leverage Zend\Config\Reader to merge them per module.  I do not like using arrays for that.  Can we leverage Zend\Config somehow to add/remove configs instead of php source manipulation? If using PHP's DOMDocument can safely parse and modify the config tree with much lower chance of messing up existing configs written by users.

@alextech Shame, I think the guy gets it by now :)
RE: Zend\Config. Good idea, except there will be a few people (myself included) that do not want to add the additional overhead of calling an external class and loading up another file over a native PHP array.

@MichaelGooden  To be honest I thought same as him. It took me a long time to understand why EventManager is needed back in the day and thought it was a nuisance, until I realized the meaning of that table I linked. So knowing that pain of learning, I try to explain it as best I can when I get an opportunity.
Config wise, yes that is a problem.  But ZF already has a mindset of development vs. production mode. As do many other languages and frameworks. A framework needs a clear focus of whether it is going to be performance oriented or development speed/comfort oriented.  Zend has been in the second.  So its not a huge leap to make configs finalized and written out somewhere when put in production mode.

@alextech I must apologise, I have been working with ZF2 since beta and forget people don’t always have the same expanse of experience that I do ;) That table is actually a good resource to link to, my brain skipped over the link at first.
Zend\Config actually supports reading and writing to PHP arrays, as well as XML (oh god why), JSON (< the best non-array one), YAML (it has a funny name :), and .INI (because some people are stuck in the 90s)
It wouldn't be hard to include in the script the option to use whichever one you want. Scan /config/ (excluding /config/autoload/) for all files with supported file extensions, and invoke the correct config adapter accordingly.

Remember that the config we're talking about is the list of modules loaded by ModuleManager. Not the module's own config as returned by Module::getConfig()

@MichaelGooden true it does support reading and writing arrays but I was afraid it will still be an issue cine PHP arrays are subject to unpredictable custom logic.  But now that @akrabat clarified exactly which configs we are talking about then it should not be a problem. I thought we were discussing list of modules loaded PLUS configs for those modules. I stand corrected.

Even if only the application config is manipulated, including and exporting will remove any comment, use of named constants like APP_ROOT and break any internal logic in the file. Better create a separate config for auto generated content and parse/merge/cache that in the index.php. I am not sure how to do this and keep a good order of modules, though.
Or merge user application config with auto generated into one new merged application config and just change index.php to use the new merged config.
@alextech and others thanks for the link and explaining - upon taking a second look at the Mvc Application I accept EventManager cannot easily be made optional and as I already mentioned I don't mind it. I don't see a problem with other components, if they are added to MVC stack and require Events you just add EventManager at that point. Problem is with event usage within Mvc Application. Also since  ModuleManager is required that needs the EventManager as well.

I realized in explanation I glossed over what lifecycle management actually means. In any MVC framework, it is not possible to tell what stage it is at without some form of event system. Most reliable way to tell the world that MVC has, for example, moved from processing controller action and entered response stage is through event system where MVC will let EventManager know its current position in its work and if you as MVC user or an additional component needs to act on it, it will be possible.
Regarding configs, thats why I propose to not use PHP config itself to discourage users from modifying it by hand or to do that in a very limited way, using JSON like @MichaelGooden brought up, or XML which I like but most seem to be against.  But if it is as @akrabat says where the only place that gets modified is the module loader then will have to make a giant disclaimer in the documentation to be aware that that file is not meant to be used to configure the application and any custom ones should be kept within the module and merged at Module.php only.

@MichaelGooden wouldn't it make more sense to write the modules into an own file like vendor/zend/composer-plugin/installed_modules.php with a file which would look like
<?php
/* THIS FILE WAS GENERATED FROM THE ZF-COMPOSER-INSTALL-SCRIPT
DO NOT MODIFY THIS FILE */

return [
    'Zend\Log',
    'Zend\FooModule',
];

which i then could load and merge into my init_application.php script which would look something like
<?php

// ...
$applicationConfig = require 'application/config.php';
$installedModules = require 'vendor/zend/composer-plugin/installed_modules.php';

$config = array_merge_recursive($applicationConfig, $installedModules);

This way, your composer script could modify its own file and its decoupled from messing with the my code.
Zend would provide something like an own module loading config which i'm then free to use or not. It would also mean that in my application.config.php i just reference my own modules and do not need to care about third-party modules anymore.

You asume vendor folder location. This could be customized and don't be available. The point of use classes is the autodiscover feature of class autoloaders so you can use without any knowledge of the directory tree.

I've tested the minimum packages required for execute the test suite of zend-expressive-zendrouter
zend-expressive-zendrouter

Installed (17)

zend-diactoros     zend-form         zend-mvc             zend-uri
zend-escaper       zend-http         zend-psr7bridge      zend-validator
zend-eventmanager  zend-hydrator     zend-servicemanager
zend-expressive    zend-inputfilter  zend-stdlib
zend-filter        zend-loader       zend-stratigility

Used (9)

zend-diactoros   zend-http  zend-psr7bridge  zend-stdlib  zend-validator
zend-expressive  zend-mvc   zend-servicemanager  zend-uri

Unused (8)

zend-escaper zend-eventmanager zend-form zend-hydrator
zend-inputfilter zend-filter zend-loader  zend-stratigility

2 of 5 required MVC dependencies are used.

@akrabat in my opinion View should be only a interface (abstract, something) that helps me to use or implement a template engine or a render library.
Current Zend\Mvc\View could be a stand alone component (template engine.. some of twig, plates..)
In my opinion in order to split this components

Zend\Log
Zend\Cache
Zend\Session
Zend\Authentication
Zend\Form
Zend\Console
Zend\Serializer
i18n
..

We can create a FrameworkModule or we can add the Module.php on each component..
In my opinion a module is more clean..
This module should contains

Specific controller plugins
Services

I know that we are only moving all dependencies from Mvc to a module.. but it could be a good change.
Module borns to use third part components on ZF2 application.. The best way to create independent components is to be yourself third part, without shortcuts or reduction :)
A single module for each component sounds good but it is very strong to maintain.. it serves a strong team

Finally at a point where we can start acting on this, and will respond to a few things before beginning.
Table of Contents

Responses to Feedback
Current Status
Proposed Dependencies
Roadmap

Responses to Feedback
@MichaelGooden — regarding this:

So depending on what it detects, you might get a prompt

I like that idea! Considering the module list varies between the ZF skeleton app and that in Apigility, an ZendDevelopmentTools recommends something else as well, this is a nice compromise. We can even have a default that is used when the --no-interaction flag is available.
@hoppithek and @Maks3w — regarding this:

For a ZF3 app EM could be required as part of the parent composer and not here.

The EventManager is a hard requirement of the current MVC, as everything that occurs is the result of triggered events: bootstrapping, routing, dispatching, rendering the view, and sending the response are all events. We are not proposing a substantial refactoring of the MVC; it's field-tested and works. What we're proposing is reducing the components to produce a "core" MVC distribution, and that work is primarily centered around the Zend\Mvc\Service subcomponent, which provides the bulk of the wiring between MVC applications and the individual ZF components.
@alextech — regarding this:

So its not a huge leap to make configs finalized and written out somewhere when put in production mode.

You can currently use any configuration format you want that is supported by Zend\Config\Reader, including XML and JSON (and YAML, if you do a little extra configuration to tell the reader how to parse YAML); we simply default to PHP as a) it's performant, b) it allows usage of constants, including ::class, and c) it does not require learning a configuration format.
Regardless of the format you use, the ConfigListener from zend-modulemanager can be configured to cache configuration, meaning any heavy-lifting of parsing configuration can be done precisely once, and then cached for all subsequent requests. My point is: this is a solved problem in ZF2 already.
@hoppithek — regarding this:

Even if only the application config is manipulated, including and exporting will remove any comment, use of named constants like APP_ROOT and break any internal logic in the file. Better create a separate config for auto generated content and parse/merge/cache that in the index.php. I am not sure how to do this and keep a good order of modules, though.

Not true. We managed a way to update configuration in zend-component-installer that uses static parsing, retaining all comments and formatting.
@Maks3w — regarding this:

2 of 5 required MVC dependencies are used.

which was in your comment detailing what components were installed when testing zend-expressive-router, this is largely irrelevant: zend-expressive-router is using the zend-mvc Router subcomponent, which is not itself event-driven. @DASPRiD is already discussing moving that to a separate repository precisely because it can be used standalone without the rest of the MVC.
@gianarb — regarding this:

in my opinion View should be only a interface (abstract, something) that helps me to use or implement a template engine or a render library.

That would be a major refactor, and a major change to the current workflow. For better or for worse, rendering is done as a separate event, and itself triggers events to allow both rendering content and updating the response; it's not as simple as just calling something like render(...). (If you want that, look at zend-expressive-template!)
And regarding this:

We can create a FrameworkModule or we can add the Module.php on each component..
In my opinion a module is more clean.

Why is it "more clean"?
What I see is an explosion of repositories, and code going out-of-sync between the individual components and the "module" repositories, as capabilities are added to the components, but not exposed in the factories provided in the modules. Considering that today we have more than 50 components, this is not a trivial concern.
Current Status
Now, for the update.
I alluded to this earlier, but I created a "component installer", zend-component-installer as a proof of concept a couple months ago. This installer is something you install in your application, and it adds both a Composer script class, as well as updates your composer.json, so that each time you first install a component, it will update your application configuration with the module, pushing it to the top of the module list (this is done to allow your own modules, or even third-party modules, to override component configuration).
Components opt-in to the workflow by adding the following to their composer.json:
"extra": {
  "zf": {
    "component": "Some\Component"
  }
}

This works surprisingly well and consistently. What I'd like to do is:

adapt it to prompt for the configuration file to update, per the suggestion from @MichaelGooden ; this should also allow providing an arbitrary file, in the same way that the Expressive installer allows providing arbitrary packages.
adapt it to accommodate both components and modules (the latter would be appended to the module list, vs prepended).

Additionally, another idea has been floating. In Expressive, we're planning to adopt mtymek/expressive-config-manager into our workflow. In that paradigm, an invokable class is used to provide application configuration. My thought is that the Module classes should either:

implement __invoke() and have it proxy to getConfig() (or vice versa), or
have getConfig() instantiate and invoke a configuration class (e.g., return (new Config())();)

In each case, this would allow re-use across both ZF and Expressive, and potentially pave a new path forward for shipping configuration with components in a re-usable fashion.
Proposed Dependencies
Having spent way too much time in zend-mvc while refactoring for forwards-compatibility with existing v3 components, what I see is the following:
Required components

zend-eventmanager (which provides the internal workflow engine)
zend-servicemanager and container-interop (from which all services are retrieved)
zend-view (used within the default workflow; however, if you return responses from your listeners and/or controllers, it can be omitted, but omission fails the default use cases as outlined by @akrabat above)
zend-http (not required for console-only applications, but required for the default use cases as outlined by @akrabat above)
zend-modulemanager (used by the Application during bootstrapping)

Semi-required components

zend-stdlib (for things like ArrayUtils::merge() and error handling; most of that functionality could likely be duplicated in the component itself to reduce dependencies)
zend-psr7bridge (used by the MiddlewareListener, which is registered by default. However, if no routes map to middleware, no classes from this component are ever used)
zend-console (used for routing and in the view layer; if you're not defining any console routes, and not using any 3rd party tools that do, it's irrelevant. However invocation of public/index.php from the CLI will fail if it's not present)

Everything else
Everything else can and should be removed. This includes:

zend-authentication
zend-cache
zend-di
zend-filter
zend-form
zend-hydrator
zend-i18n
zend-inputfilter
zend-json
zend-log
zend-session
zend-serializer
zend-text
zend-uri (this is a dependency of zend-http anyways)
zend-validator
zend-version (this component is legacy at best at this time)

Interestingly, there are other components not currently in the composer.json that likely could stand the module treatment, too, due to their common appearance in applications:

zend-navigation
zend-paginator
zend-db
zend-ldap
zend-mail

Roadmap
At this point, my plan is:

Copy factories, abstract factories, etc. to their individual components.
Create Module and/or similar classes in these components.
Tag new minor releases of these components containing the above.
Remove each component receiving that treatment as a dependency of zend-mvc (on the develop branch).

@weierophinney thanks for this summary!

Create Module and/or similar classes in these components.

About this point, in your opinion we can exclude something like FrameworkModule?
It could contain the suggested integration of all ZF ecosystem with Zend\Mvc, we can install this module as default into the ZendSkeletonApplication in order to maintain a similar experience for the users that don't care about witch components use or not.
But we will be a strong Mvc component without don't required dependencies and we don't dirty each component with a out of place Module.php (or whatever will be) file.
In practice we are only moving all dependencies in a module but only because create a "integration module" for each components it's more expensive (but i think that it is the most clean solution).

@gianarb My argument for pushing into the components themselves is to allow simplified re-use regardless of the framework.

The factories belong with the components. Most of the dev dependencies exist to test factories. In a number of cases, I found the tests for these factories in the components themselves, which was an odd dependency inversion.
How the factories are wired into the service container should be part of the component. The rationale? If I want to re-use the component in, say, zend-expressive, right now I have to duplicate that configuration (and, in many instances, the factories themselves!). Having the component be able to provide that default configuration to me makes it easier for me to consume the component, regardless of context. (Of course, this begs for a standard around container configuration and mappings.)

What you describe, with a single module bringing in all current dependencies, is what should be in the skeletons; we can have multiple skeletons, targeting multiple use cases (e.g., a minimal skeleton, a "kitchen sink" skeleton with everything currently in ZF2, an API-centric skeleton, etc.). The main argument I can see for creating a module is for having a single thing to drop-in to existing applications when they upgrade to zend-mvc v3, and the approach of having each component exposed as a module does not mean we cannot or should not do that as well; it just allows for more flexibility and granularity.
While I understand the allure of omitting integration-related classes from the components, from a position of (a) managing the repositories, (b) thinking about overall dependencies, and (c) considering syncing issues, splitting this stuff into separate modules is a nightmare.

(a) as noted before we can have N*2 repositories (module repository per component), N+1 repositories (components + an integration module), or N repositories. Seeing as N repositories are already hard to manage, why should we add more?
(b) communicating that a developer needs to not add zend-i18n, but zend-i18n-module, is a nightmare. Developers will inevitably install the former, and wonder why things don't "just work". Telling them to use zend-i18m-module then becomes a FAQ. Anytime you need a FAQ, you need to ask if you're paving the cow path, or ignoring it. Additionally, users end up complaining about the fact that they need to install two dependencies for what is, as a consumer, only one. This may seem trivial, but when you look at folks in countries or regions with less available bandwidth and/or data caps, it's not. On top of that, it makes understanding why certain things are installed harder.
(c) We've already encountered problems due to new features being introduced into components, but the factories in zend-mvc being behind; moving that into an integration module, or even a module repository per component, does not make that problem go away, and that's a problem I'd really like to solve, as it makes my life and the life of other maintainers simpler.

I think a module containing all current ZF dependencies does make sense, but feel strongly it needs to be done in addition to having each component exposed as a module/configuration provider. The module will mainly exist to allow developers with existing applications an easy way to upgrade, and/or for folks looking for that "full stack" experience an easy path that does not involve individually installing each package (though this latter will likely be served by a skeleton).

New finding: zend-stdlib is definitely required; we use it for DispatchableInterface, which consumes its own RequestInterface and ResponseInterface, as well as its SplQueue implementation.

I understand, I try to do some questions:

Where we move the factories we must add Zend\ServiceManager dependency as "require" or you suggest to add another "suggest if you use" this factory?
Other point is the controller plugins, for example the IdentityPlugin will be move into the Zend\Authentication, with Zend\Mvc as "suggest if you use" dependency?

communicating that a developer needs to not add zend-i18n, but zend-i18n-module, is a nightmare

The skeleton application will contains all modules, if someone decide to start your own skeleton will be
informed because we will write it into the docs or because he has some skills and he will understand the composer.json configuration.

it makes my life and the life of other maintainers simpler

It's a good point but I received the same feedback before our spit from different current maintainers but now the same people, after the slit, they assess the result better.

@weierophinney Thanks for summing this up. I still say "including and exporting" will remove a lot from the file. The alternative you suggest: static parsing, which in the linked examples breaks down to a preg_replace of the file content is possible, but will just as often fail. Nonetheless, as long as the files being manipulated are simple, I think it will work. If it doesn't it might still be possible using source tokenization and adding the entries that are needed while rebuilding code from tokens.

@gianarb —

Where we move the factories we must add Zend\ServiceManager dependency as "require" or you suggest to add another "suggest if you use" this factory?

Most of these already have a dependency on zend-servicemanager. In the few cases where they do not, yes, it becomes a suggested dependency (and a development requirement).

Other point is the controller plugins, for example the IdentityPlugin will be move into the Zend\Authentication, with Zend\Mvc as "suggest if you use" dependency?

No, these will stay in zend-mvc. Plugins are points of integration, and should stay there. In those cases, the dependency becomes a suggestion, as not all plugins are used in every application.

communicating that a developer needs to not add zend-i18n, but zend-i18n-module, is a nightmare
The skeleton application will contains all modules, if someone decide to start your own skeleton will be
informed because we will write it into the docs or because he has some skills and he will understand the composer.json configuration.

You're making the assumption that everyone starts from the same skeleton. For users who are upgrading, this is not the case. Additionally, one of the suggestions made in this and other threads is that we have multiple skeletons, targeting different use cases. As such, we cannot assume that all components are necessarily present, and need a mechanism for automating installation of new components with their default configuration.

@MichaelGooden I've updated zend-component-installer to act as a composer plugin, and it now addresses the various criteria you outlined (discovering the multiple configuration files supported, prompting as to which one to inject into, allowing the option of "no injection"). At this point, that puts us in a position that we can start the work of separating out the various component-specific functionality into the components themselves.

Roadmap posted to https://github.com/zendframework/maintainers/wiki/zend-mvc-v3-refactor:-reduce-components

Completed as of #128 !!!!


fix(tests): Missing artifacts (include-hidden-files)

upload-artifact updated behavior: Hidden Files will be excluded by default
https://github.com/actions/upload-artifact/issues/602
Need to include
include-hidden-files: true

@alexanderankin this is needed to make the CI tests pass.
Sadly https://github.com/actions/upload-artifact/issues/602 did a breaking change without adhering to semantic versioning..

fascinating


Add checklist issue number to config.json

Now that we've added a "Help Launch" section to upcoming languages, it'd be really nice to link directly to the checklist issue for the course instead of linking with search params (source).
We can add the checklist issue number to the config.json and safely default it to 1 since @kytrinyx posts the issue via the API as soon as a language repo is created.

+100 Thanks for remembering to add this issue.
Here's the list of repositories that have an open "Launch Checklist" issue:

[ ] assembly    [4] https://github.com/exercism/xassembly/issues/4
[ ] bash        [4] https://github.com/exercism/xbash/issues/4
[ ] c           [8] https://github.com/exercism/xc/issues/8
[ ] coldfusion  [1] https://github.com/exercism/xcoldfusion/issues/1
[ ] crystal     [1] https://github.com/exercism/xcrystal/issues/1
[ ] dlang       [6] https://github.com/exercism/xdlang/issues/6
[ ] groovy      [9] https://github.com/exercism/xgroovy/issues/9
[ ] haxe        [2] https://github.com/exercism/xhaxe/issues/2
[ ] kotlin      [1] https://github.com/exercism/xkotlin/issues/1
[ ] nim         [13] https://github.com/exercism/xnim/issues/13
[ ] perl6       [30] https://github.com/exercism/xperl6/issues/30
[ ] pony        [1] https://github.com/exercism/xpony/issues/1
[ ] powershell  [4] https://github.com/exercism/xpowershell/issues/4
[ ] r           [5] https://github.com/exercism/xr/issues/5
[ ] racket      [1] https://github.com/exercism/xracket/issues/1
[ ] sml         [8] https://github.com/exercism/xsml/issues/8
[ ] tcl         [1] https://github.com/exercism/xtcl/issues/1
[ ] teco        [1] https://github.com/exercism/xteco/issues/1
[ ] vbnet       [3] https://github.com/exercism/xvbnet/issues/3

Thanks!
I still need to locate where the config.json is generated for new tracks and add checklist_issue with the default value of "1".

Here you go: https://github.com/exercism/x-template

I've gone ahead and opened PRs for the above tracks except for those that have a Launch Checklist issue of 1 since we're defaulting to that.
Once this PR and the others are merged, we can move forward with https://github.com/exercism/exercism.io/issues/2875

Bam! We are good to go.


thread 'main' panicked at 'called Result::unwrap() on an Err value: reqwest::Error

Hello, I ran the docker image and it crashed.  Here's the log:
thread 'main' panicked at 'Username required', src/config.rs:73:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
config selected = /app/config/config
[INFO] - locast2tuner 0.1.15 on Linux 5.10.1-Unraid starting..
[INFO] - UUID: 2b97e7a7-a137-4bea-9af2-aeab226cd40a
[INFO] - Logging in with<EMAIL_ADDRESS>[DEBUG] - starting new connection: https://api.locastnet.org/
[DEBUG] - response '200 OK' for https://api.locastnet.org/api/user/login
[INFO] - Login succeeded!
[DEBUG] - starting new connection: https://api.locastnet.org/
[DEBUG] - response '200 OK' for https://api.locastnet.org/api/user/me
[DEBUG] - starting new connection: https://api.locastnet.org/
[DEBUG] - response '200 OK' for https://api.locastnet.org/api/dma
[INFO] - Downloading FCC facilities
[DEBUG] - starting new connection: https://transition.fcc.gov/
[DEBUG] - redirecting 'https://transition.fcc.gov/ftp/Bureaus/MB/Databases/cdbs/facility.zip' to 'https://transition.fcc.gov/Bureaus/MB/Databases/cdbs/facility.zip'
[DEBUG] - response '200 OK' for https://transition.fcc.gov/Bureaus/MB/Databases/cdbs/facility.zip
[INFO] - Cached FCC facilities to /root/.locast2tuner/facilities
[DEBUG] - starting new connection: https://api.locastnet.org/
[DEBUG] - response '200 OK' for https://api.locastnet.org/api/watch/dma/zip/60601
[DEBUG] - starting new connection: https://api.locastnet.org/
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: Url { scheme: "https", username: "", password: None, host: Some(Domain("api.locastnet.org")), port: None, path: "/api/watch/epg/602", query: Some("startTime=2021-04-14T00:00:00-00:00&hours=192"), fragment: None }, source: hyper::Error(Connect, ConnectError("dns error", Custom { kind: Other, error: "failed to lookup address information: Try again" })) }', src/utils.rs:22:36

stack backtrace:
0: rust_begin_unwind
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/panicking.rs:92:14
2: core::result::unwrap_failed
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/result.rs:1355:5
3: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
6: <futures_util::future::join_all::JoinAll<F> as core::future::future::Future>::poll
7: locast2tuner::main::{{closure}}
8: tokio::macros::scoped_tls::ScopedKey<T>::set
9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
10: tokio::macros::scoped_tls::ScopedKey<T>::set
11: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on
12: tokio::task::local::LocalSet::block_on
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If more information would be helpful I can up the verbosity level to full.  Thanks for the awesome work you do!

@TheSamDickey My docker version runs fine once I renamed config.ini to config.  Is it only failing on system startup, or can you ever get it to start?
Your logs kind of look a bit odd, though - The error in the first line would probably be related to the config file not being found due to the change for #35.  But the rest appears to be more of a connectivity issue.
(@wouterdebie We might want to consider calling out the config change prominently for some of the early-adopters who used config.ini and then to update their package or Docker image.)

@eiddor Yeah, it wouldn't run at all until I changed the config.ini to config.  This log was after changing over to just config.
It ran for about 30 seconds before failing.  It seems to have worked properly up until it was starting to log into api.locastnet.org.

Getting  a similar error over the past few days. Recently had to change config.ini to config as well. Happens as soon as the Docker starts.
config selected = /app/config/config [INFO] - locast2tuner 0.1.15 on Linux 5.10.21-Unraid starting.. [INFO] - UUID: REMOVED [INFO] - Logging in with REMOVED [INFO] - Login succeeded! thread 'main' panicked at 'calledResult::unwrap()on anErr` value: reqwest::Error { kind: Decode, source: Error("invalid type: null, expected i64", line: 1, column: 274) }', src/credentials.rs:97:10
stack backtrace:
0: rust_begin_unwind
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/panicking.rs:92:14
2: core::result::unwrap_failed
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/result.rs:1355:5
3: locast2tuner::main::{{closure}}
4: tokio::macros::scoped_tls::ScopedKey::set
5: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
6: tokio::macros::scoped_tls::ScopedKey::set
7: tokio::runtime::basic_scheduler::BasicScheduler::block_on
8: tokio::task::local::LocalSet::block_on
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread 'main' panicked at 'called Result::unwrap() on an Err value: reqwest::Error { kind: Decode, source: Error("invalid type: null, expected i64", line: 1, column: 274) }', src/credentials.rs:97:10
stack backtrace:
0: rust_begin_unwind
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/panicking.rs:92:14
2: core::result::unwrap_failed
at ./rustc/c755ee4ce8cae6ea977d65a0288480940db721d9/library/core/src/result.rs:1355:5
3: locast2tuner::main::{{closure}}
4: tokio::macros::scoped_tls::ScopedKey::set
5: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
6: tokio::macros::scoped_tls::ScopedKey::set
7: tokio::runtime::basic_scheduler::BasicScheduler::block_on
8: tokio::task::local::LocalSet::block_on
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
`

@TheSamDickey for some reason Docker seems to suffer some transient network issues. I'll implement some retry/exponential backoff behavior to mitigate this.
@rtm2017 this is a different error. After logging in, it seems that the user info doesn't contain the donationExpire flag. I'll add some debugging output to see what the response is you're getting. Do you have an active (paid for) locast.org account?

Alright sounds good!  Thanks!

@wouterdebie  You were right, think I got it all working now! Sorry to bother you!

@rtm2017 No worries! It exposed a bug though, where the error handling wasn't correct. I'm fixing this now.

@TheSamDickey I just pushed v0.1.17, which has retry behavior. This should fix your issue.

Im having this same issue running the unraid template, should I just run it in an ubuntu VM container so I can change the config.ini?

@deputyd0ng Can you tell me the exact issue you're having?  Renaming the config.ini to config was one problem, but the ultimate issue that @TheSamDickey had seemed to be something transient upstream and v0.1.17 added some retry behavior to mitigate against it.
We may have to open a new issue if your problem is different or something specific to how unraid runs containers.


Laptop freezes and blacks out when I type, then get PowerToys error

Microsoft PowerToys version
<IP_ADDRESS>
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
When I'm typing, sometimes my laptop will freeze up, go black for a second and then a few seconds later, it finally comes back. Twice now it has come up with this error, but it occurs more often than I get the error.
Version: <IP_ADDRESS>
OS Version: Microsoft Windows NT 10.0.22621.0
IntPtr Length: 8
x64: True
Date: 2/23/2024 11:59:52 AM
Exception:
System.Runtime.InteropServices.COMException (0x80263001): {Desktop composition is disabled} The operation could not be completed because desktop composition is disabled. (0x80263001)
at Standard.NativeMethods.DwmExtendFrameIntoClientArea(IntPtr hwnd, MARGINS& pMarInset)
at System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame()
at System.Windows.Shell.WindowChromeWorker._UpdateFrameState(Boolean force)
at System.Windows.Shell.WindowChromeWorker._HandleDwmCompositionChanged(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Shell.WindowChromeWorker._WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
✔ Expected Behavior
To type without my computer blacking out.
❌ Actual Behavior
When I'm typing, doesn't matter if it's in an email or word document or in a browser somewhere, randomly it will freeze and cause my screen to go black for a few seconds, then come back up. Seems like a computer aneurism. Then I got this error message.
Other Software
Version: <IP_ADDRESS>
OS Version: Microsoft Windows NT 10.0.22621.0
IntPtr Length: 8
x64: True
Date: 2/23/2024 11:59:52 AM
Exception:
System.Runtime.InteropServices.COMException (0x80263001): {Desktop composition is disabled} The operation could not be completed because desktop composition is disabled. (0x80263001)
at Standard.NativeMethods.DwmExtendFrameIntoClientArea(IntPtr hwnd, MARGINS& pMarInset)
at System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame()
at System.Windows.Shell.WindowChromeWorker._UpdateFrameState(Boolean force)
at System.Windows.Shell.WindowChromeWorker._HandleDwmCompositionChanged(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Shell.WindowChromeWorker._WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

/dup #31226


Add the ability to create group controls on dash

Related to https://github.com/datalens-tech/datalens/issues/89

Closes https://github.com/datalens-tech/datalens/issues/89


Cannot create initial build, app policy AdministratorAccess not valid

ARN arn:aws:iam:aws:policy/AdministratorAccess is not valid. (Service: AmazonIdentityManagement; Status Code: 400; E
rror Code: InvalidInput; Request ID: xxxxxxxxxxxxxxxxxxxxxxx; Proxy: null)

Hello
I think this issue arose from running this command:
env CDK_NEW_BOOTSTRAP=1 npx cdk bootstrap \ --cloudformation-execution-policies arn:aws::iam:aws:policy/AdministratorAccess \ aws://<ACCOUNT-ID-NUMBER>/us-east-2
I received the same error message when running this command. Then I looked at the documentation of cdk bootstrap:
--cloudformation-execution-policies
The Managed Policy ARNs that should
be attached to the role performing
deployments into this environment
(may be repeated, modern
bootstrapping only)
[array] [default: []]

--cloudformation-execution-policies attaches the policy to an IAM role, but I did not have any IAM role defined. So the error might have been caused that the CDK tried to assign a policy to a role that did not exist in the first place. When I removed the parameter, the bootstrapping succeeded, and the output told me in yellow print (=warning?):
Using default execution policy of 'arn:aws:iam::aws:policy/AdministratorAccess'. Pass '--cloudformation-execution-policies' to customize.
So you should define an IAM role that you use when running this script.

Aha, I was wrong. The reason why it is invalid is because of the colons in the ARN. Both @rotatopoti and I had a typo in the policy ARN. The correct form is:
arn:aws:iam::aws:policy/AdministratorAccess
Notice that there are two colons after iam. I had the two colons in the wrong place.


feat: send pause when hitting inflight barrier limit

Signed-off-by: tabVersion<EMAIL_ADDRESS>I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
PLEASE DO NOT LEAVE THIS EMPTY !!!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)
resolve #6682

I suggest not reusing the Pause command in the meta service (while the same mutation should be acceptable). Pause is specialized for scaling and does much more than pausing the source executors, like:

always do a checkpoint
ask compute nodes to wait for epoch in post_collect
pause the concurrent checkpoint

These're not throttling the source throughput wants.
By the way, I guess making the throttle on the source executor more aggressive will solve this problem much more easily. 🤔 cc @yezizp2012

I suggest not reusing the Pause command in the meta service (while the same mutation should be acceptable). Pause is specialized for scaling and does much more than pausing the source executors, like:

always do a checkpoint
ask compute nodes to wait for epoch in post_collect
pause the concurrent checkpoint

These're not throttling the source throughput wants.

👍 Indeed, introducing anther command with pause mutation will avoid all these unnecessary effects.

By the way, I guess making the throttle on the source executor more aggressive will solve this problem much more easily. 🤔 cc @yezizp2012

strongly +1 as I said in #6682 🥵 , @fuyufjh What do you think?

By the way, I guess making the throttle on the source executor more aggressive will solve this problem much more easily. 🤔 cc @yezizp2012

strongly +1 as I said in #6682 🥵 , @fuyufjh What do you think?

I'll be happy with any easier solution. ☺ Can you elaborate more on "making the throttle on the source executor more aggressive"?


Cache ci dependencies

We can cache both the results from deno (https://github.com/denoland/setup-deno/issues/31#issuecomment-1209782606) as well as the downloaded types in .denoTypes and the downloaded npm_packages. We could also cache node_modules but the plan is to get rid of these eventually so that's not a priority.

Thanks for the example. Mine even seems to cache the chrome install for puppeteer automatically!
For the others like me

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      DENO_DIR: deno_dir
    steps:
      - name: Setup repo
        uses: actions/checkout@v3

      - name: Setup .env secrets file
        run: echo $ENV_GITHUB_ACTIONS | base64 -d > .env
        env:
          ENV_GITHUB_ACTIONS: ${{ secrets.ENV_GITHUB_ACTIONS }}

      - name: Setup Deno
        # uses: denoland/setup-deno@v1
        uses: denoland/setup-deno@004814556e37c54a2f6e31384c9e18e983317366
        with:
          deno-version: v1.25.1

      - name: Cache Deno dependencies
        uses: actions/cache@v3
        with:
          # The Chrome install gets cached too
          # import_map.json as key doesnt always work,
          # if is not enough, we can add more files here.
          key: denoDeps-${{ hashFiles('import_map.json') }}
          path: ${{ env.DENO_DIR }}

      - name: Install Chromium for Puppeteer
        run: PUPPETEER_PRODUCT=chrome deno run -A --unstable<EMAIL_ADDRESS>
      # Verify the use of 'deno fmt' on each commit.
      - name: Verify formatting
        run: deno fmt --check


slack join link is not active anymore

click on "join slack" in the navbar

Hey @mathematikoi, sorry about that! I'll update it, but for now, here you go! https://join.slack.com/t/json-schema/shared_invite/zt-1ywpdj4yd-bXiBLjYEbKWUjzon0qiY9Q

Thanks for raising the issue, much appreciated!


Upgrade to sanity/client@3

Library looks great!
Get peer dependency conflict when using<EMAIL_ADDRESS>

@jfulse While running force works fine, I definitely want to support this. Just merged a pull request in and upgrade the version to 1.4.1 to allow for this! Let me know if you still have issues.


[auto-merge] bot-auto-merge-branch-24.12 to branch-25.02 [skip ci] [bot]

auto-merge triggered by github actions on bot-auto-merge-branch-24.12 to create a PR keeping branch-25.02 up-to-date. If this PR is unable to be merged due to conflicts, it will remain open until manually fix.

SUCCESS - auto-merge


[PL-50980] PL 1.37.6 Release Notes

PL-50980
https://harness.atlassian.net/wiki/spaces/PD/pages/21775286273/NG+Release+SAAS+May+6th+2024+for+1.37.x-+Build
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663c8c03d99d08899aacee36--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663c8c8ad9697c86b2ec3271--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663cbfb3b53863b48a72dda5--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663deaf3283574de957554f4--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6641df2da80f9299cb79b57e--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6641df5c93dcbb9ef8643ae6--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66436f02cee04e2fa9ee24f6--harness-developer.netlify.app


add --tag option

The "iterate on modules"  doc shows the --tag option.
I'd like that as an option for this action.
Thanks!

@TonyPapousekLC The buf-push-action always includes the Git commit as the --tag. Were you thinking that you'd like to override that behavior?

@marekbuild - Yup, my team sets that field as the project semver

I second this, needed for the exact same reason, thanks.

@sachaw can you propose what you'd like to see exactly? ie what you want added to the configuration, what the behavior should be, get as detailed as you can. We'd like to consider this.

Hey we'd love this option too, I see the current action sets it to --tag ${{ github.sha }}, if it was me my suggestion would be to add an input with that as the default e.g.:
inputs:
    tag:
        required: false
        type: string
        default: ${{ github.sha }}

Then replace the existing step to have: WANT_ARGS: push path/to/input --tag ${{ inputs.tag }}

With the suggestion above, then in ur own case we would be able to use it as:
- uses: bufbuild/buf-push-action@v1
  with:
    input: <path-to-protos>
    buf_token: ${{ secrets.buf_token }}
    tag: ${{ github.sha }},<other-tag>,<even-more-tags>

Any progress so far? We are also using semver so we have to maintain own fork for that. There is already PR #36 created

This has been sitting for a bit. I ended up here with the same ask. Any way we can get a quick update to this action? Seems like a pretty simple thing to solve for.

The update here is we are investing in a new unified GitHub action. It is in an alpha state here: https://github.com/bufbuild/buf-action so you are welcome to try it out. We are already dogfooding it internally and have received positive feedback from a few other customers.

@nicksnyder where I can left feedback to that new action? I noticed 2 issues

Missing documentation for github_token as I see in the code it is used, but it is not documented in the README
That tag option during push is not available there too. So no benefits to migrate there now

You can file issues on the buf-action repo.

Missing documentation for github_token as I see in the code it is used, but it is not documented in the README

Thanks, we'll add docs for those.

That tag option during push is not available there too. So no benefits to migrate there now

Tags and Branches are deprecated as of v1.32.0 of the buf CLI. We now have a single concept called Labels (which is backward compatible with Tags and Branches).
The new action automatically adds a label for each git ref that points to the git commit you are pushing to the BSR, so if you are tagging with semver Git tags, then those will automatically get pushed to the BSR (without the need for any manual configuration). Does that solve your use case?
Here are some blog posts that explain the changes:

https://buf.build/blog/buf-cli-next-generation
https://buf.build/blog/enhanced-buf-push-bsr-ui

@nicksnyder thanks for the reply. I will need to test it out. It should work as you described it, but I'm not 100% sure as our trigger is repository_dispatch, not push.
When we merge changes to master branch, they are not pushed to BSR automatically. But after our code reach production, we are using Github API to trigger that workflow, with semver tag as payload.
Our pipeline looks like this (very simplified):
---
name: Push Proto changes to buf.build
on:
    repository_dispatch:
        types: [publish_proto] # Do not rename type as this is identifier in external cURL call

jobs:
    buf-push:
        strategy:
            matrix:
                repos:
                    - {fullName: indykite/indykiteapis, folder: proto/public}
                    - {fullName: indykite/internalapis, folder: proto/internal}
        runs-on: ubuntu-latest
        steps:
            # ...
            - if: ${{ steps.diff_checker.outputs.has_diff }}
              uses: bufbuild/buf-setup-action@v1
              with:
                  github_token: ${{ secrets.INDYKITEONE_PAT }}

            - if: ${{ steps.diff_checker.outputs.has_diff }}
              uses: bufbuild/buf-lint-action@v1
              with:
                  input: ${{matrix.repos.folder}}
            - if: ${{ steps.diff_checker.outputs.has_diff }}
              uses: bufbuild/buf-push-action@v1
              with:
                  buf_token: ${{ secrets.BUF_TOKEN }}
                  input: ${{matrix.repos.folder}}
                  tag: ${{ steps.get-tag.outputs.new_tag }}
              env:
                  BUF_TOKEN: ${{ secrets.BUF_TOKEN }}

@arxeiss The push action is really just a thin wrapper around buf push, so it is just as easy, if not simpler, to call buf push directly.
-              uses: bufbuild/buf-push-action@v1
-              with:
-                  buf_token: ${{ secrets.BUF_TOKEN }}
-                  input: ${{matrix.repos.folder}}
-                  tag: ${{ steps.get-tag.outputs.new_tag }}
+              run: buf push ${{ matrix.repos.folder }} --label ${{ steps.get-tag.outputs.new_tag }}

@nicksnyder
Hello,
I have not transitioned to the new actions and keep using this one.
Today, I pushed a new commit to BSR, but there's a main label and
it was not updated by this action.
As a result, buf dep update does not seem to get the new commit
pushed by this action. Is this intended?

The new buf-action has been released as a v1 with improved support for push, ensuring branches kept in sync with the BSR. Please take a look and raise any issues found there! Happy to help on buf slack or GitHub issues for any setup help in migrating buf-push-action to the new action.


Update get coord by type

Pull Request Checklist:

[x] This PR addresses an already opened issue (for bug fixes / features)

This PR relates to https://github.com/roocs/catalog-maker/issues/11

[x] Tests for the changes have been added (for bug fixes / features)

Looks good @ellesmith88. Have you checked it doesn't break the clisops and daops tests as well? Thanks

@agstephens yes, checked and they all pass 🙂

Great stuff!


Fix 'Disabled Pressable' example on Pressable page

Description
Change Disabled pressable example so that it no longer performs an action.
Why
Resolves #363
What
Removed different display messages when Pressable was being pressed.
Screenshots
Before:

After:

From the behaviour before, it looks like this may be a bug in pressable, as the text when pressed should not show up when the disabled prop is set to true. I have temporarily modified the example, but not sure if I should instead leave as is and open a tracking issue on the RNW repo.

From the behaviour before, it looks like this may be a bug in pressable, as the text when pressed should not show up when the disabled prop is set to true. I have temporarily modified the example, but not sure if I should instead leave as is and open a tracking issue on the RNW repo.

Closing to leave example page as is.


refactor(sozo): change priority order for arguments

fix: #1336
to be consistent with what we did for torii: https://github.com/dojoengine/dojo/pull/800, i think we should follow this priority, wdyt?
passed cli argument
Environment variable
Scarb.toml 's dojo.tool.env

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (e599968) 65.95% compared to head (a7a2c46) 67.01%.
Report is 5 commits behind head on main.

Files
Patch %
Lines

crates/sozo/src/commands/options/account.rs
0.00%
2 Missing :warning:

crates/sozo/src/commands/options/starknet.rs
83.33%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1358      +/-   ##
==========================================
+ Coverage   65.95%   67.01%   +1.05%
==========================================
  Files         228      231       +3
  Lines       19841    20788     +947
==========================================
+ Hits        13087    13931     +844
- Misses       6754     6857     +103

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

(don't merge, need to check the coverage report and add relevant test)

fix: #1336
to be consistent with what we did for torii: #800, i think we should follow this priority, wdyt?
passed cli argument
Environment variable
Scarb.toml 's dojo.tool.env

:heavy_check_mark: Agree on this priority list.

CLI is explicit so you user do want something specific.
Env var as they are very common and offer great flexibility.
The manifest allows a simple and quick way to alter those variables.

I initially did cli arg -> scarb.toml -> env var under the assumption that Scarb.toml is perceivably more explicit that env. As user might get confused if they accidentally set both env and Scarb.toml, and have to wonder why the values are different than their Scarb.toml, which is more visually apparent for them then setting an env var.
But I think having env before Scarb.toml might make sense especially when you wanna quickly set those values without having to open a file and edit/delete them manually.
I'm open on changing the priority order if it make sense from user perspective.

I initially did cli arg -> scarb.toml -> env var under the assumption that Scarb.toml is perceivably more explicit that env. As user might get confused if they accidentally set both env and Scarb.toml, and have to wonder why the values are different than their Scarb.toml, which is more visually apparent for them then setting an env var.
But I think having env before Scarb.toml might make sense especially when you wanna quickly set those values without having to open a file and edit/delete them manually.
I'm open on changing the priority order if it make sense from user perspective.

Also I think env variables are very commonly used to alter the behavior of a program while keeping the configuration private. Which can't be done using the scarb manifest. So having the priority changed can allow one to keep dev/frequent config inside the scarb manifest which automatically configures the project for someone that pull the code and don't have to setup any other thing. And the env takes precedence on CI/deploy where more sensible information should be hidden.
Does this make sense to you too guys?
It could be great to have a poll somewhere or a way to have a feedback from users on that.

Does this make sense to you too guys?

Yeah i think the reasoning makes sense

My vote is for cli arg > env > config and i think that is fairly expected

Also I think env variables are very commonly used to alter the behavior of a program while keeping the configuration private. Which can't be done using the scarb manifest. So having the priority changed can allow one to keep dev/frequent config inside the scarb manifest which automatically configures the project for someone that pulls the code and doesn't have to setup any other thing. And the env takes precedence on CI/deploy where more sensible information should be hidden.

Make sense, I agree.

Do you mind following this up with a PR for adding tests to AccountOptions similar to the one we have for StarknetOptions?

Sure.
I had a suggestion regarding the tests in StarknetOptions, since environment variables are handled by clap, i think we don't specifically need to tests for environment variables in all the cases.
we can just have one tests which verifies that environment variables are been read, and for all other tests we can pass the arguments directly to Command::parse_from function.
wdyt?

though we can do that change in follow up PR along with addition of tests in AccountOptions

Sure.

Thanks!

I had a suggestion regarding the tests in StarknetOptions, since environment variables are handled by clap, i think we don't specifically need to tests for environment variables in all the cases.

Yeah, I think as long as we can check that it'll fallback to Scarb.toml then should be good


Datum information lost when converting file with datum D_Amersfoort

If I use Fiona to read a file in a coordinate system with D_Amersfoort as the datum and copy the metadata into a new file, I get D_Unknown as the datum.
Original .prj file:
PROJCS["RD_New",GEOGCS["GCS_Amersfoort",DATUM["D_Amersfoort",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Double_Stereographic"],PARAMETER["False_Easting",155000.0],PARAMETER["False_Northing",463000.0],PARAMETER["Central_Meridian",5.38763888888889],PARAMETER["Scale_Factor",0.9999079],PARAMETER["Latitude_Of_Origin",52.15616055555555],UNIT["Meter",1.0]]

.prj file after conversion:
PROJCS["Double_Stereographic",GEOGCS["GCS_Bessel 1841",DATUM["D_unknown",SPHEROID["bessel",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Double_Stereographic"],PARAMETER["latitude_of_origin",52.1561605556],PARAMETER["central_meridian",5.38763888889],PARAMETER["scale_factor",0.9999079],PARAMETER["false_easting",155000],PARAMETER["false_northing",463000],UNIT["Meter",1]]

This leads to a pretty significant shift in the location of the geodata.
Using ogr2ogr to convert the same file behaves correctly, so it looks like this is a Fiona problem (or a bug in my use of Fiona). The code I'm using is here.
Finally, the file I'm using is from Statistics Netherlands (page in dutch, but it's the buurt_2014.shp file inside the first link): http://www.cbs.nl/nl-NL/menu/themas/dossiers/nederland-regionaal/publicaties/geografische-data/archief/2015/wijk-en-buurtkaart-2014-art.htm .

Oh, should add that this is with fiona 1.6.1 and gdal 1.11.2 on OS X 10.10.5.

@mattwigway in your code, I see that the new file is given a coordinate reference system obtained from the crs property of the original dataset. It's possible that some information is lost in converting the original projection to a PROJ4 representation (see https://github.com/Toblerity/Fiona/blob/master/fiona/ogrext.pyx#L560).
Can you confirm for me that the following code gives you the coordinate reference system you expect? And if there's a difference between infile.crs_wkt and infile.crs?
with fiona.open(argv[1]) as infile:
    print(infile.crs_wkt)

We could look into using crs_wkt when creating new files if it will always be more precise than crs.

Yes it does:
>>> with fiona.open('buurt_2014.shp') as inf:
...     print inf.crs_wkt
...
PROJCS["RD_New",GEOGCS["GCS_Amersfoort",DATUM["Amersfoort",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Oblique_Stereographic"],PARAMETER["False_Easting",155000.0],PARAMETER["False_Northing",463000.0],PARAMETER["Central_Meridian",5.38763888888889],PARAMETER["Scale_Factor",0.9999079],PARAMETER["Latitude_Of_Origin",52.15616055555555],UNIT["Meter",1.0]]
>>>

I propose to fix this bug by adding a new crs_wkt keyword argument to fiona.open() and also adding a crs_wkt item to meta. As far as I can tell, the WKT crs form is more precise than the PROJ4 form: if crs_wkt and crs are both passed, as would be the case when you take a meta dict and pass it back to open(), crs_wkt would trump crs.
/cc @Toblerity/pushers

Sounds good to me, thanks!

Ah hmm. The crs_wkt has the datum listed as Amersfoort rather than D_Amersfoort, but that may be equivalent.

@mattwigway your code is exactly right, and my proposed change requires no changes on your part. I hope the datum name change is just a GDAL implementation detail. We'll see!


Feat/lesq 879/share query [LESQ-879]

Description
Music year: {owa_music_year}

update share query to use lesson_content and browse MVs
update curriculum schema version
update types for pupil schemas: lessonContent, lessonBrowseData and unitBrowseData

How to test

Go to https://deploy-preview-2474--oak-web-application.netlify.thenational.academy/teachers/programmes/chemistry-secondary-ks4-l/units/atomic-structure-and-the-periodic-table-u68nqqc/lessons/atoms-elements-and-compounds-h3hasv/share?preselected=all
It should look the same as https://www.thenational.academy/teachers/programmes/chemistry-secondary-ks4-l/units/atomic-structure-and-the-periodic-table-u68nqqc/lessons/atoms-elements-and-compounds-h3hasv/share?preselected=all
It should link to the pupil lesson overview page
The pupil journey should all still work: https://deploy-preview-2474--oak-web-application.netlify.thenational.academy/pupils/years

Screenshots
How it used to look (delete if n/a):

How it should now look:

Checklist

lesson share pages work for legacy content
share resource cards show the correct metadata (video duration, quiz question count etc)
pupil pages all work and show correct data

:tada: This PR is included in version 1.453.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


npm install error with chromedriver

npm ERR! Darwin 15.6.0
npm ERR! argv "/Users/zxb/.nvm/versions/node/v6.8.1/bin/node" "/Users/zxb/.nvm/versions/node/v6.8.1/bin/npm" "install"
npm ERR! node v6.8.1
npm ERR! npm  v3.10.8
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node install.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node install.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the chromedriver package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node install.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs chromedriver
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls chromedriver
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/zxb/Desktop/work/javascript-lean/vue-lean/simple/npm-debug.log

Which template were you using. Tested with webpack template and everything worked well

I am using the webpack template

i am try the webpack-simple template and is ok.

Hi,
I'm trying the webpack template, and I get the same error.
Running in an Ubuntu virtual box (vagrant under windows)

me too


Error importing /data/json/mapgen/campsite.json

I clicked file->Import cdda map
Entered my project dir and the json file /home/user/Documents/GitHub/Cataclysm-DDA-1/data/json/mapgen/campsite.json
Got this error
TypeError: Cannot read property 'rows' of undefined
Stack traceback:
  constructor@file:///home/user/.config/tiled/extensions/CDDA_Map_extension.mjs:712
  importMap@file:///home/user/.config/tiled/extensions/CDDA_Map_extension.mjs:445
  @file:///home/user/.config/tiled/extensions/CDDA_Map_extension.mjs:958

I think it's because campsite.json starts with a monstergroup not mapgen

I think it's because campsite.json starts with a monstergroup not mapgen
This is correct, it was looking for the first entry to get the map size. Now it's getting the map size from the first entry that is a json mapgen, which is not great since entries can have different sizes.
Also broken was that the logic to check if there is a palette defined seems broken, and then it starts looking for palettes.


GetBrowserInfo() Error in chrome

In omnibar.js
The
let browserName
;(async () => {
    const browserInfo = await browser.runtime.getBrowserInfo()
    browserName = browserInfo.name
})()

Throws an Error in chrome as the function  browser.runtime.getBrowserInfo() isn't supported. see this link
I don't fully understand why the name is needed?

I found the solution to this through webmemex @ this commit
However I can't push my branch cause of permission errors =(


Link is broken

The link to download gives a 404.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 65973393-2cb9-a656-01b8-7963a7a40b39
Version Independent ID: 22e2323b-18c3-ad2b-174c-84fbf642715e
Content: Hosting Bundle
Content Source: aspnetcore/host-and-deploy/iis/hosting-bundle.md
Product: aspnet-core
Technology: aspnetcore-hostdeploy
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Thanks @capesean ... I'll patch that up right now. In the meantime, you can get the latest release Hosting Bundle installer here (under ASP.NET Core Runtime 5.0.8 on the right) ...
https://dotnet.microsoft.com/download/dotnet/5.0

@capesean ... I can't repro that. Perhaps, it was just a temporary network failure.

I'm still getting it. I thought it might be due to cookies but In Private I still get it.

Maybe a regional redirect (coming from South Africa)?
Separate issue, but installing from the direct link has blown up my development environment - see below.

I'm probably doing something stoopidly wrong here. All I was trying to do it test if I could publish to a folder for a client to host on their IIS server, as it's currently published to Azure. I kept getting 500.19 errors, seemed to indicate I needed to install the self-hosting module, but now it's all gone to pot. Can you recommend somewhere I can get chat help from - gitter maybe? Rushing to get it installed on client infrastructure...

Let's ask @shirhatti ... ☝ There might be a regional problem obtaining the Hosting Bundle Installer from the permalink. Do you want to dig deeper here or move this issue?

Ok, I went back to the page and it seems to work for me now. Not sure why, but I'd close this off as I'm sure you've got more important issues to worry about. (Sorry, not sure why I was getting that 404)

No worries, @capesean ... probably just a glitch in the Matrix.© :smile:

Agent Smith (Hugo Weaving) ©1999 Warner Brothers Entertainment, Inc.


“Brain Graph Off” when switch workspace

Brain graph shows the note  the same as I save the workspace, won't change when I click on another note.
I remember there was a "Brain Graph On" command in the earlier version, cannot find it now.

plugins:

Workspaces Plus 0.3.1
Excalidraw 1.6.33
ExcaliBrain 0.0.22
Key Promoter 1.2.2 ( which shows the “Brain Graph Off” command.

but "ExcaliBrain Normal" will not refresh or open Brain Graph for me.

It seems fixed after updating Obsidian to v0.15.1.
Switch workspace will turn Brain Graph on/off, bug?
"ExcaliBrain Normal" now works.

Obsidian 0.15.1 brings some very significant changes to the underlying Obsidain environment. As of right now, I am not sure how/if I will be able to address them all. WIP, but will take lots of effort/time to figure out how/what to do.

The problem disappeared in Obsidian v0.15.2.


Hack aqara with ZHA integration

Greetings,
I have aqara sensor with ZHA integration but appdaemon_aqara_motion_sensors not resat my sensor to 5 second.
I have config in app.yaml with appdaemon 4.

also having this issue but with deconz

the same issue here.. my motion sensors are connected with ZHA integration and their state isnt reset after 5 seconds even though I did hardware hack and also installed this app to appdaemon4

same here

Same here.
Is there any solution available for ZHA?

I don't have a dongle to test ZHA or DeConz with.
This app listens specifically for the Xiaomi Aqara integration's motion event
self.listen_event(self.motion_sensor_state_on, "xiaomi_aqara.motion", entity_id=entity_id)
If you provide more info on the ZHA and DeConz integration's event's I can add it.

You may find alternate solutions to ZHA or DeConz at https://community.home-assistant.io/t/aqara-motion-sensor-hack-for-5-sec/147959/30

Please try the latest release v1.2.0 for ZHA

v1.2.0 works fine for me (HA core-2021.9.1 with ZHA).
This is top, thanks so much!

Greetings,
I have aqara sensor with ZHA integration but appdaemon_aqara_motion_sensors not resat my sensor to 5 second. I have config in app.yaml with appdaemon 4.

Has the ZHA update fixed this for you?


Add allow-unrecognized Flag

Allow undefined CDO concepts to be exempted and not cause a failure.

Adds a new allow-unrecognized flag or CASE_ALLOW_UNRECOGNIZED to not fail on unrecognized CDO concepts.

My review boils down to a matter of maintenance opinion.
I believe, personally, that the feature introduced in this pull request is harmful, via application of the Robustness Principal: "Be conservative in what you send, and liberal in what you accept".  I am, again personally, a subscriber to the spirit of RFC 9413:

Time and experience show that negative consequences to interoperability accumulate over time if implementations silently accept faulty input.

This PR introduces a feature that says it is permissible to a user to ignore warnings in specifically the IRIs in data professing to be a part of a CDO ontology or CDO-adopted ontology.
For better or worse, case-utils currently offers no such specific support.  Warnings of undefined CDO IRIs are treated with the same severity as sh:Warning-severity constraint violations from SHACL validation reports: If the data is validated with case_validate --allow-warnings, all warnings are accepted(/excepted).  So, in implementation, the feature in this PR has an effect that is incongruous with its keywording.
I am not personally happy with the idea of putting effort into supporting such a split in warning categories.  If a graph has a typo'd IRI, I believe it should be fixed in the generating application.  If a graph tried using a new custom concept under a CDO namespace, I believe it should go into some drafting namespace, rather than attempt to search CDO resources for a concept definition that it won't find, or induce pain on downstream data adopters when they can't integrate data from that faulty generator.
For the moment, I am a NACK on this PR because of the effect-scope incongruity.  I'm more comfortable with this PR adding an option to expose allow_warnings via call-environment configuration.  That and allow_infos are features that case-utils forwards from pyshacl, and pyshacl implements those from design induced by sh:severity, so SHACL already opened the "Here's how to ignore warnings" door.  I'm not comfortable introducing a new subtle way to have faulty data.


[BUTTON IDEA]:

1. Name of button: PlayStore & Appstore
2. Description: Download from PlayStore & AppStore
3. Button Type (Animated, Special, etc...):PlayStore & AppStore
4. Will you work on it?:Yes for sure

Thank you for your idea @imsikun . Due to certain guidelines when it comes to these buttons, as these buttons are usually images downloaded from Google or Apple, I think it's best if you don't add them.


Life Cycle Events

Is there documentation on all the events in the ui grid life cycle?  At onRegisterApi, the gridApi is registered, but the columns are not yet populated.  Is there another event where all the columns are populated?

The columns are populated asynchronously.  Usually we use onRegisterApi + run a $interval.
There is not currently documentation on all the events in the grid lifecycle, there is some documentation that is related to that in http://ui-grid.info/docs/#/api/design-rendering-cycle

I created a directive that use ui-grid in the template.  I needed to create an external filter.  This filter is outside of the grid.  So I used what others have talked about here and hard set the filter term.  However, since the columns are not yet populated in onRegisterApi, I can't set the term there.  I ended up using $timeout in my directive's link function to set the filter term.  It would be great if there is onGridPopulated in addition to onRegisterApi.


[6.x] Improve cookie encryption

Hello - are there any extra details on this? It seems to break my authentication, or at least it's broken on 6.18.31. I've had to downgrade to 6.18.26 in the meantime. Any modifications we need to make? Thanks.

@danielsefton please open an issue with detailed steps to reproduce if something's broken for you.


Prisma Client: logging not done in transactions

Bug description
I'l logging my queries using the prisma.$on-method. But no logs will be written within an (interactive!) transaction.
How to reproduce

setup a simple prisma client
register $on() to log queries
create a query / update within this transaction

Expected behavior
Logging should be the same.
Prisma information
generator client {
  provider = "prisma-client-js"
  previewFeatures = ["interactiveTransactions", "fieldReference"]
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

model Device {
  imei         String @id @db.VarChar(15)
  eId          String? @db.Char(32)
  ban          String @db.VarChar(20)

  brand        String @db.VarChar(60)
  model        String @db.VarChar(60)

  owner        String? @db.VarChar(60)
  email        String? @db.VarChar(60)

  subscriber   Subscriber? @relation(fields: [serialNumber], references: [serialNumber])
  serialNumber String?     @unique @db.VarChar(25)
  serialNumberUnchecked String? @db.VarChar(25)

  source    deviceSource
  createdAt DateTime     @default(now())
  changedAt DateTime     @updatedAt
  @@unique([ban, serialNumberUnchecked])
}

model Ban {
  id            String   @id @default(cuid()) @db.Char(32)
  toBeSynced    Int?
  synced        Int?
  syncStartedAt DateTime?
  subscribers   Subscriber[]

  createdAt  DateTime @default(now())
  changedAt  DateTime @updatedAt
}

model Subscriber {
  banId                  String           @db.VarChar(20) @default("")
  serialNumber           String           @unique @db.VarChar(20)
  subscriberNumber       String           @db.VarChar(20)
  productType            String           @db.VarChar(20)
  subscriberStatus       subscriberStatus
  simType                simType
  eSimStatus             eSimStatus
  pushStatus             pushStatus       @default(UNKNOWN)
  tariffName             String           @db.VarChar(60)

  device                 Device?
  ban                    Ban              @relation(fields: [banId], references: [id], onDelete: Cascade)

  createdAt              DateTime         @default(now())
  changedAt              DateTime         @updatedAt

  @@id([banId, serialNumber])
  @@index([banId, subscriberNumber])
}

model BulkPush {
  id         String         @default(cuid()) @db.Char(32) @id
  ban        String         @db.VarChar(20)

  pushStatus BulkPushStatus @default(WAITING_TO_START)
  start      DateTime?
  end        DateTime?
  items      BulkPushItem[]

  createdAt DateTime @default(now())
  changedAt DateTime @updatedAt
}

model BulkPushItem {
  bulkId       String             @db.Char(32)
  eId          String             @db.Char(32)
  serialNumber String             @db.VarChar(25) //@unique
  //    subscriber              Subscriber?     @relation(fields: [serialNumber], references: [serialNumber])
  pushStatus   BulkPushItemStatus @default(IN_QUEUE)
  pushResult   String?

  createdAt    DateTime           @default(now())
  changedAt    DateTime           @updatedAt

  bulkJob      BulkPush           @relation(fields: [bulkId], references: [id], onDelete: Cascade)

  @@id([bulkId, serialNumber])
  @@unique([bulkId, eId])
  @@index([pushStatus])
}

enum subscriberStatus {
  ACTIVE
  CANCELLED
  RESERVED
  SUSPENDED
}

enum simType {
  PSIM
  ESIM
}

enum eSimStatus {
  // ordering important for sorting
  // free first, than progress, than error states
  // unavailable at the end, unknown last
  AVAILABLE
  IN_PREPARATION
  LINK_TO_EID_PREPARATION
  READY_FOR_DOWNLOAD
  DOWNLOAD_IN_PROGRESS
  ERROR_NOTIFICATION
  UNLINK
  CANCELLED
  REMOVED
  INSTALLED
  UNKNOWN
}

enum pushStatus {
  AVAILABLE_FOR_PUSH
  PROCESSING
  PUSHED
  CONNECTED
  ERROR
  UNKNOWN
}

enum deviceSource {
  MDM
  UPLOAD
}

enum BulkPushStatus {
  WAITING_TO_START
  IN_PROGRESS
  SUCCESSFUL
  FAILED
}

enum BulkPushItemStatus {
  IN_QUEUE
  IN_PROGRESS
  SUCCESSFUL
  FAILED
}

enum BanStatus {
  UNKNOWN
  SYNCING
  SYNCED
}

Environment & setup

OS: macOS
Database: MySQL / MariaDB
Node.js version: v16.18.0

Prisma Version
prisma                  : 4.5.0
@prisma/client          : 4.5.0
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 0362da9eebca54d94c8ef5edd3b2e90af99ba452 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 0362da9eebca54d94c8ef5edd3b2e90af99ba452 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core 0362da9eebca54d94c8ef5edd3b2e90af99ba452 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt 0362da9eebca54d94c8ef5edd3b2e90af99ba452 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.5.0-43.0362da9eebca54d94c8ef5edd3b2e90af99ba452
Default Engines Hash    : 0362da9eebca54d94c8ef5edd3b2e90af99ba452
Studio                  : 0.476.0
Preview Features        : interactiveTransactions, fieldReference

@volkerrichert this is really strange. Could you provide a replication for this error. Also have you enabled logging on the client?

I'll try to brake it down.

@volkerrichert Thank you for reporting, I have confirmed this is a bug and we will look into it.

Sorry just updating this. We have a test for this https://github.com/prisma/prisma/blob/main/packages/client/src/tests/integration/happy/logging/library.ts#L78 and I've manually confirmed that the logging works correctly. This isn't a bug in the client. I'm guessing something in your setup is incorrect. If you could paste your setup maybe we can see where the issue is. One important thing is to check that the client emitting the log is the same one that is running the transaction.

is there any "easy way" to check it? Does Object.is() does the job?

No problem. Thanks for letting me know.

Hm, i did a deep dive into my code. I import the prisma client like descibed in the "log running app" doc. And then i stepped through my transaction code. It look slike
this.prisma.$transaction((tx) => {
// some transaction magic here ;.)
})

you pointed out that the prisma client must be the same, but Object.is(this.prisma, tx) is false. I expected them to be equal... both are proxies, having a PrismaClient as it's target.
Where will the $on callbacks be stored inside prisma client?

ok, I thing i fixed it. I'm using prism in a sandbox async worker which seems to create a new instance by importing the prisma client and not reusing it. So, i reinit my logging service. THAX for your help


Update RouteAttributesServiceProvider.php

fix #18

The tests are failing for this one, could you fix them?

The tests are failing for this one, could you fix them?

Closing because of failing tests.


Can't understand this structure: public skript class hippo.classes.P2Listener

Describe the bug
Upon loading this skript file, I got 2 errors (see additional context).
This snippet worked (without any error) with an older version of Skript, skript-reflect, Hippo (v1) and paper obviously (paper 1.19).
import:
	com.plotsquared.core.player.PlotPlayer
	com.plotsquared.core.plot.Plot
	com.plotsquared.core.PlotAPI
	com.plotsquared.core.PlotSquared
. . .

preimport:
	hippo.classes.P2Listener

public skript class hippo.classes.P2Listener:
	public P2Listener():
		super[]()
		set {PlotAPI} to new PlotAPI()
		{PlotAPI}.registerListener(this)

	@Subscribe
	public void onPlayerEnterPlot(PlayerEnterPlotEvent event):
		# Test code
		set {_plot} to {_event}.getPlot()
		broadcast "%{_plot}%"

on load:
	if {PlotListener} is set:
		PlotSquared.get().getEventDispatcher().unregisterListener({PlotListener})
	set {PlotListener} to new P2Listener()

Expected behavior
Load correctly my skript file.
Server information
hippo: 1.1
skript-reflect: 2.4-dev1
Skript: 2.7.1
Server Verion: git-Paper-261 (MC: 1.20.2)
Minecraft: 1.20.2
Java: 17.0.7 (OpenJDK 64-Bit Server VM 17.0.7+7-Debian-1deb11u1)
OS: Linux amd64 5.10.0-24-amd64

Additional context
You can find here complete stack trace of the reload:
> sk reload CreatifMenu
[00:42:24 INFO]: Line 81: (CreatifMenu.sk)
[00:42:24 INFO]:     Can't understand this structure: public skript class hippo.classes.P2Listener
[00:42:24 INFO]:     Line: public skript class hippo.classes.P2Listener:
[00:42:24 INFO]:
[00:42:25 INFO]: Line 172: (CreatifMenu.sk)
[00:42:25 INFO]:     Your code reached reference of not yet compiled class 'hippo.classes.P2Listener'. Make sure this pre-imported class got compiled without problems. (Expected problem: Class does not exist)
[00:42:25 INFO]:     Line: set {PlotListener} to new P2Listener()
[00:42:25 INFO]:
[00:42:25 INFO]: [Skript] Encountered 1 error while reloading CreatifMenu.sk! (1361ms)

Syntax has been changed, you no longer use the full class name but just the pre-imported alias, P2Listener in this case.
The 'skript' keyword in the class definition can also no longer be used.
`
public class P2Listener:
public P2Listener():
super
set {PlotAPI} to new PlotAPI()
{PlotAPI}.registerListener(this)
@Subscribe
public void onPlayerEnterPlot(PlayerEnterPlotEvent event):
	# Test code
	set {_plot} to {_event}.getPlot()
	broadcast "%{_plot}%"

`


Adding field names to allow ipfix yaml mapping field to parse

Addresses #89. This change makes the default mapping.yaml file parse correctly.

Thank you!