Implement PEP 660 hooks in setuptools/build_meta.py

Summary of changes
Implements the hooks required to support PEP 660 -- Editable installs for pyproject.toml based builds (wheel based). Resolves #2816.

dholth's work which I referenced extensively: https://github.com/dholth/setuptools_pep660

I chose the root .pth editable strategy as it "just works" for implicit namespace packages and also looked easier haha. While most of the code is (hopefully) rather straightforward, it is quite verbose as unforunately setuptools doesn't have much in terms of wheel utilties.
There's also a somewhat sketchy hack used to acquire the distribution location so I can put the right path to ${dist-name}.pth in the wheel. Since the PEP 517 is isolated from the command framework, it's pretty hard querying information from the various setup.py commands ran. The shim added captures the egg_info instance when setup.py dist_info runs so the build_editable hook can query the location (i.e. egg_base).
One limitation of this commit is that the build_editable hook completely ignores the metadata_directory parameter and violates the guarantee the hook shall produce a (editable) wheel with identical metadata. Given that it seems no major backends is currently following through with this promise this is hopefully fine for now?
Pull Request Checklist

[ ] Changes have tests (nope, still gotta figure this out)
[ ] Test out more non-standard packaging configurations
[ ] Test out packages with extensions
[ ] Create wheel_directory if doesn't exist already when build_editable is called
[x] News fragment added in changelog.d/.

FWIW this is my first contribution to setuptools so I'm a little nervous I've messed everything up. Hopefully this isn't too bad :)

https://github.com/pypa/setuptools/runs/4180806139?check_suite_focus=true#step:5:204

WARNING: Built editable for setuptools is invalid: Wheel has unexpected file name: expected '58.5.3.post20211111.post-20211111', got '58.5.3.post20211111.post'

Well apparently dist.version is not a valid version?
>>> import setuptools.dist
>>> setuptools.dist.Distribution._normalize_version("58.5.3.post20211111.post-20211111")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ichard26/programming/oss/setuptools/setuptools/dist.py", line 484, in _normalize_version
    normalized = str(packaging.version.Version(version))
  File "/home/ichard26/programming/oss/setuptools/setuptools/_vendor/packaging/version.py", line 277, in __init__
    raise InvalidVersion("Invalid version: '{0}'".format(version))
setuptools.extern.packaging.version.InvalidVersion: Invalid version: '58.5.3.post20211111.post-20211111'

Alright, implementing this patch:
diff --git a/setuptools/build_meta.py b/setuptools/build_meta.py
index a24eb0f7..4e377916 100644
--- a/setuptools/build_meta.py
+++ b/setuptools/build_meta.py
@@ -49,7 +49,7 @@ import setuptools.command.egg_info
 import distutils

 import pkg_resources
-from pkg_resources import parse_requirements
+from pkg_resources import parse_requirements, safe_name, safe_version

 __all__ = ['get_requires_for_build_sdist',
            'get_requires_for_build_wheel',
@@ -313,7 +313,11 @@ class _BuildMetaBackend(object):
         dist = pkg_resources.DistInfoDistribution.from_location(
             location, dist_info, metadata=metadata
         )
-        wheel_name = f'{dist.project_name}-{dist.version}-ed.py3-none-any.whl'
+        # Seems like the distribution name and version attributes aren't always
+        # 100% normalized ...
+        dist_name = safe_name(dist.project_name).replace("-", "_")
+        version = safe_version(dist.version).replace("-", "_")
+        wheel_name = f'{dist_name}-{version}-ed.py3-none-any.whl'
         wheel_path = os.path.join(wheel_directory, wheel_name)
         with zipfile.ZipFile(wheel_path, 'w') as archive:
             archive.writestr(f'{dist.project_name}.pth', location)

Avoids the weird error message from pip (due to misreading the not normalized distribution name), but then predictably uncovers this issue:
  Building editable for setuptools (pyproject.toml) ... done
  Created wheel for setuptools: filename=setuptools-58.5.3.post20211111.post_20211111-ed.py3-none-any.whl size=9822 sha256=050f33119d1f68404c8eed8007f9870d5cc49e40fcd4dd3edb5c4d7e1adfc50f
  Stored in directory: /tmp/pip-ephem-wheel-cache-tb3eq2fm/wheels/29/a6/99/6cd5ddea9b773be0e848527e54dd03b1092fe671cb9b561ab5
  WARNING: Built editable for setuptools is invalid: Metadata 1.2 mandates PEP 440 version, but '58.5.3.post20211111.post-20211111' is not
Failed to build setuptools
ERROR: Could not build wheels for setuptools, which is required to install pyproject.toml-based projects

Is this is a short-coming in my implementation or can I safety assume non-440 are not my problem :slightly_smiling_face:

TIL that egg_info and dist_info can return different versions.

Considering that PEP 660 requires backends to choose how to implement editable installs and the fact that pip will fall back to setup.py develop, I'm inclined to say that when we implement PEP 660 we should try and clean up some of the major failings of the current editable install mode. Specifically, I think we should use a "strict" approach, where we only install what the config files says to install, rather than the current approach where we YOLO it by dumping all the relevant paths onto the PYTHONPATH.
I don't see any rush to implement this, so it'd be better to do it right than to do it quickly.

TIL that egg_info and dist_info can return different versions.

That's definitely unintentional. dist_info is preferable. Let's figure out why the metadata is incorrect and work on correcting that and supporting that format.

One thing I'd like to suggest is that __legacy__ should basically mimic python setup.py develop. That would minimize distruption to existing projects that pip uses setup.py for directly, when pip switches over to using the pyproject.toml based isolated build environments.

 I'm quite busy right now but I can look into revisiting this implementation soon.

Specifically, I think we should use a "strict" approach, where we only install what the config files says to install, rather than the current approach where we YOLO it by dumping all the relevant paths onto the PYTHONPATH.

Can you provide some direction on how this would be accomplished?

I feel that the initial pass of PEP 660 support should replicate the current behaviour, as that's what users expect and are used to. And I agree with @pradyunsg that the __legacy__ backend should definitely use the .pth mechanism, as the whole point of the __legacy__ backend is to replicate current behaviour.
Further iterations could then investigate other implementation mechanisms that make different trade-offs than the current .pth file mechanism does.

Can you provide some direction on how this would be accomplished?

I think it's pretty obvious how this could be accomplished. I seem to remember there was a proof of concept implementation kicking around when PEP 662 was being discussed. I seem to remember thinking it was easier than I thought it was going to be, but I can't find a copy of it. Maybe @gaborbernat was the one who did it?

I feel that the initial pass of PEP 660 support should replicate the current behaviour, as that's what users expect and are used to. And I agree with @pradyunsg that the __legacy__ backend should definitely use the .pth mechanism, as the whole point of the __legacy__ backend is to replicate current behaviou

I disagree on both counts here. The legacy behavior is fundamentally broken, and since PEP 660 forces us to make choices for our users rather than letting them make their own trade-offs,  we should choose correctness. setuptools already has a confusing morass of behaviors that are very hard to intuit. People are constantly shipping tests and examples packages, and even I have trouble explaining the various interactions between package_data and include_package_data and MANIFEST.in.
I think people expect pip install -e . to install the package as it would be installed normally, but with live updating of the code. They also expect new files to show up automatically. Unfortunately, these two options are in conflict, and we need to make a choice. Considering that editable installs not adding new files automatically fails loudly while editable installs doing something subtly incorrect fails quietly and most likely after a wheel has been released, it seems like the obvious choice is to fix this long-standing bug as part of the PEP 660 implementation.
It doesn't seem likely that we need to worry about backwards compatibility here because this will primarily affect interactive workflows rather than automated ones — some people may be relying on the accidental feature that more stuff is included in editable installs than in normal installs for their production systems, but this is simply a bug in their setup.py that they are accidentally working around by installing via a mechanism that doesn't respect the metadata they actually specified.

The legacy behavior is fundamentally broken, and since PEP 660 forces us to make choices for our users rather than letting them make their own trade-offs, we should choose correctness.

You can use the config_settings mechanism to allow users to select between options. (I'd be happy to support improving pip's UI for passing config settings to the backend, if that turns out to be needed to make this work). So having an option to use the legacy behaviour certainly doesn't preclude adding other behaviours. And if, as you say, a better option would be an unequivocal improvement, I doubt anyone would object if you changed the default once that approach was added (particularly if they had a config option to request the older behaviour, should they for some reason want it).

You can use the config_settings mechanism to allow users to select between options. (I'd be happy to support improving pip's UI for passing config settings to the backend, if that turns out to be needed to make this work). So having an option to use the legacy behaviour certainly doesn't preclude adding other behaviours. And if, as you say, a better option would be an unequivocal improvement, I doubt anyone would object if you changed the default once that approach was added (particularly if they had a config option to request the older behaviour, should they for some reason want it).

Yeah, I definitely agree that PEP 660 provides a clunky backend-specific non-standard way to allow users to choose their editable install mode. I don't think we can really rely on that or expect people to discover or use it, particularly when, as I mentioned, the problems with the current editable install mode are subtle and quiet, whereas the users will discover the problems with their assumptions quickly and loudly with the strict mode.
I seem to recall during the PEP 660 discussions that everyone in favor of PEP 660 seemed fine with the idea that backends should choose what their install mode would be, and since "strict" is really the only mode that makes sense for setuptools (as I mentioned many times), it is a natural consequence of PEP 660 that setuptools would use strict installation mode automatically.
Depending on the implementation, it might make sense for there to be a dedicated command class that can be used to customize the behavior of editable installs.

If that's the route you want to take, I'll flag that it will be disruptive to users in situations where they can't easily control the setuptools version (like pip's isolated build environments).
To that end, I encourage doing things to reduce user pain due to it: documenting the failure modes with some amount of clarity in the documentation, clear communication about the change with known regressions clearly stated, and so on. If you can do some sort of opt-in/opt-out via build_config or an environment variable, that would help users mitigate their immediate breakage as well, reducing the amount of toxicity you'd need to deal with when the release goes out.

If that's the route you want to take, I'll flag that it could be disruptive to users in situations where they can't easily control the setuptools version (like pip's isolated build environments).

To some extent I agree that PEP 660 deliberately chooses to move the choices about trade-offs into the hands of backend implementers, something I was very concerned with, and one of the main reasons I thought PEP 660 was a bad design.
On the other hand, the PEP 660 proponents had at least some point when they said that this is much less of a problem for editable installs than for normal installs, because this sort of thing would only ever be a problem if you are installing from source code, which you can easily change. I can't think of any examples where someone would be doing an editable install using pip's isolated build environment in such a way that non-strict installations would matter and they wouldn't be able to easily modify pyproject.toml to specify a setuptools version. In an isolated build environment you are doing a fresh install of the package every time, so there's no reason to do it in editable mode in the first place.

To that end, I encourage doing things to reduce user pain due to it: documenting the failure modes with some amount of clarity in the documentation, clear communication about the change with known regressions clearly stated, and so on. If you can do some sort of opt-in/opt-out via build_config or an environment variable, that would help users mitigate their immediate breakage as well, reducing the amount of toxicity you'd need to deal with when the release goes out.

I agree that we should document the failure modes. I think opt-in wouldn't achieve our goals because, as I said, the current behavior is broken in such a way that most users do not know it is broken, and so they will never opt-in. Opt-out might make sense, but I don't think it's critical, and I don't think we need to bend over backwards to accommodate the fact that PEP 660 is poorly designed.

In an isolated build environment you are doing a fresh install of the package every time, so there's no reason to do it in editable mode in the first place.

I believe you're misunderstanding -- the moment you release PEP 660 support in setuptools, pip's isolated build environments will start picking up the latest setuptools version and use that. If you change behaviours there, the end user has no way to make pip use a different version of setuptools (other than modifying the package's pyproject.toml). This could be exceedingly disruptive to folks who depend on the "bad" parts of the existing behaviour, who will be not-that-great to interact with for anyone involved.

I think opt-in wouldn't achieve our goals because, as I said, the current behavior is broken in such a way that most users do not know it is broken, and so they will never opt-in. Opt-out might make sense, but I don't think it's critical, and I don't think we need to bend over backwards to accommodate the fact that PEP 660 is poorly designed.

No, the opt-in -> switch default with opt-out -> drop opt-out is not to deal with "PEP 660 is bad actually". It's to deal with the fact that you want to make a backwards incompatible change as part of implementing the setuptools' PEP 660 implementation.
Even if setuptools implemented PEP 660 via a .pth file first, and then moved to adopt the strict mode, the users would still only make noise when the adoption of the strict mode happens -- because that is the breaking change.

I believe you're misunderstanding -- the moment you release PEP 660 support in setuptools, pip's isolated build environments will start picking up the latest setuptools version and use that. If you change behaviours there vs setup.py develop, the end user has no way to make pip use a different version of setuptools (other than modifying the package's pyproject.toml). This could be exceedingly disruptive to folks who depend on the "bad" parts of the existing behaviour, who will be not-that-great to interact with when they show up on the issue tracker (and will leave with a sour taste for Python as a whole).

I understand what you mean but I'm saying that I'm struggling to imagine a situation where someone would be using an editable install in an isolated build environment. Editable installs are for interactive workflows where you are making changes on the fly. pip does a fresh install of every package every time it is invoked, so editable installs should be no different from regular installs. The "strict" part that's in contention is basically because the way setup.py develop works, you can add new files after installation and have them picked up automatically, but that will never happen in an isolated build environment, which does the install and then immediately uses the package, then immediately deletes the enviornment.
AFAICT, the only reason someone would want to use an editable install during their build is if they messed up their package configuration such that normal installs install something totally different from editable installs, in which case their package is broken and it should raise an error! It's a bug, not a feature, that using an editable install can gloss over problems with your package configuration.

No, the opt-in -> switch default with opt-out -> drop opt-out is not to deal with "PEP 660 is bad actually". It's to deal with the fact that you want to make a backwards incompatible change as part of implementing the setuptools' PEP 660 support.

The reason this has to do with PEP 660 being bad is that PEP 660 opted to standardize a method where there is no standard way for end-users to configure their installation mode. If there were, setuptools wouldn't even have had to make this choice at all, and front-ends could choose to fix the bug or present different installation options. They didn't, and so setuptools is forced to make a choice of doing it one way or the other.
Now that we know that there's no option for us to leave it up to end-users, we have to make a choice as to whether or not we fix the bug, and I think we should fix it. People already hate setuptools and packaging in general (with good reason!), so we may as well lean into the pain and at least give them as good a product as we can.

I think it's pretty obvious how this could be accomplished. I seem to remember there was a proof of concept implementation kicking around when PEP 662 was being discussed. I seem to remember thinking it was easier than I thought it was going to be, but I can't find a copy of it. Maybe @gaborbernat was the one who did it?

I don't know which PoC you are remembering, but I'd created frontend-editables at the time which relied on symlinking to enforce 'strictness'.  You can't have symlinks in a wheel, so how would you do this within the framework of PEP 660?

I understand what you mean but I'm saying that I'm struggling to imagine a situation where someone would be using an editable install in an isolated build environment.

pip creates an isolated build environment to call PEP 660 hooks inside of.  It will install the latest available version of setuptools in the isolated build environment.

the end user has no way to make pip use a different version of setuptools (other than modifying the package's pyproject.toml).

Surely passing --no-isolation and pre-installing setuptools would work?

I don't know which PoC you are remembering, but I'd created frontend-editables at the time which relied on symlinking to enforce 'strictness'. You can't have symlinks in a wheel, so how would you do this within the framework of PEP 660?

I don't think PEP 660 or PEP 662 differed in how things could be implemented, because you can use a PEP 662 approach and then implement the code the front-end was expecting to implement on the backend. The problem I had always had in providing setuptools proofs of concept in the (admittedly small) time I had to work on it was that setuptools mixes installation and marshalling tasks, so there was no obvious point in the workflow where you had a list of the location of everything to be copied / zipped up and the locations it had to be copied to. PEP 662 was saying that backends should construct that list and hand it to front-ends to do the installation. In PEP 660 the backend has to do all the installation work as well as all the marshalling work, but it's fundamentally the same task.
Once you have the list of files to install, you can use one of the strategies outlined in the PEP for installation. Probably the most cross-platform of which is a proxy platform using import hooks in a .pth file, but there's also an option involving the backend building a directory full of symlinks and I think adding that directory to sys.path in a .pth file.

The reason this has to do with PEP 660 being bad is that PEP 660 opted to standardize a method where there is no standard way for end-users to configure their installation mode.

I'm confused by this statement. PEP 660 has the standard config_options mechanism for this[^1]. Backends may choose not to offer multiple strategies via that route, but how is that different from the PEP 662 case where the frontend offers only a single strategy? If PEP 662 had been accepted, I'd be extremely surprised if pip implemented multiple strategies - we'd likely implement a .pth file approach and stop there. (And before you claim that's sour grapes on the part of people who support PEP 660, remember that the pip maintainers have basically all said that we consider .pth files to be sufficient, so why wouldn't we implement that strategy?)
[^1]: I'll happily concede that the UI for config_options sucks at the moment, but that is "just" a tool issue. I've said on a number of occasions that I'd be happy with improving how pip exposes config_options, it's just that we've never had a reason to prioritise doing so.

Once you have the list of files to install, you can use one of the strategies outlined in the PEP for installation. Probably the most cross-platform of which is a proxy platform using import hooks in a .pth file, but there's also an option involving the backend building a directory full of symlinks and I think adding that directory to sys.path in a .pth file.

The proxy module trick doesn't work with namespace packages.  It might not be an option for setuptools. Creating a tree of symlinks out of band and adding them to the Python path would work, but we'll have gone from drop this one file in site packages to multi-step installation and uninstallation which is unspecified and outside the control of pip.  In my opinion, PEP 660 isn't equipped to handle anything this intricate; trying to force a wheel into a square hole is only gonna end in frustration.

pip creates an isolated build environment to call PEP 660 hooks inside of. It will install the latest available version of setuptools in the isolated build environment.

Surely any users who are installing a package can edit their own pyproject.toml to add version caps to setuptools, no? The people in favor of PEP 660 seemed to think that "edit config files in the package" was an acceptable UI for end users, and if you are actually relying on the old behavior then of course you should modify your build dependencies to reflect that. Pradyun seemed to be indicating that there were situations where end users don't actually control what setuptools version they get, but would somehow also rely on this.

The proxy module trick doesn't work with namespace packages. It might not be an option for setuptools. Creating a tree of symlinks out of band and adding them to the Python path would work, but we'll have gone from drop this one file in site packages to multi-step installation and uninstallation which is unspecified and outside the control of pip. In my opinion, PEP 660 isn't equipped to handle anything this intricate; trying to force an (oversized ;) wheel into a square hole is only gonna end in frustration.

I haven't had much time to look into it, to be honest. How do other backends deal with this?
If it's true that PEP 660 backends can't even implement this correctly, then it's a much worse spec than I thought.

I'm confused by this statement. PEP 660 has the standard config_options mechanism for this1. Backends may choose not to offer multiple strategies via that route, but how is that different from the PEP 662 case where the frontend offers only a single strategy?

There is a standard way to pass options to backends, but the options themselves are specific to the backend, and I'm not even sure that all front-ends have a way to pass options via that mechanism. The point is that we have to go outside of the standard to allow end-users to configure this if it's possible at all.
I'm not saying we can't do it, just that it's a messy hack and we shouldn't expect users to discover it. The default should be strict installations.

Surely any users who are installing a package can edit their own pyproject.toml to add version caps to setuptools, no?

I don't think upper-capping setuptools in a project's build metadata solely for editable installs in development is something we'd want to encourage or even suggest.

The people in favor of PEP 660 seemed to think that "edit config files in the package" was an acceptable UI for end users, and if you are actually relying on the old behavior then of course you should modify your build dependencies to reflect that.

I don't know who thought that was an acceptable UI but even if they did, editing editable-specific metadata is fundamentally different from editing project-wide metadata to satisfy a specific purpose.

I haven't had much time to look into it, to be honest. How do other backends deal with this?

They use .pth files and a few of them use Paul's editables library for non-namespace packages. Nobody has attempted to do strict editable installs that I know.

In my opinion, PEP 660 isn't equipped to handle anything this intricate

It's not clear to me that any strategy is perfect here. Symlinks don't work on all platforms, .pth files expose too much, import hooks don't work with namespace packages. If someone can develop a strategy that actually implements whatever setuptools is trying to achieve with "correct behaviour"[^1], we'd be having a very different conversation. So far, though, no-one has produced anything that people can agree on as "working".

If it's true that PEP 660 backends can't even implement this correctly, then it's a much worse spec than I thought.

Define correct. This is not a rhetorical question, neither PEP 660 nor PEP 662 precisely defined an editable install, both using wording something along the lines of

some changes to the project code in the local source tree will become effective without the need for a new installation step. At a minimum, changes to the text of non-generated files that existed at the installation time should be reflected upon the subsequent import of the package
[...]
some differences may be visible, such as the presence of additional files (compared to a typical installation), either in the source tree or the interpreter's installation path

That's from PEP 662, PEP 660 was similar, more restrictive in some ways, less in others. Again, if we had a precise definition of what it meant to do an editable install, we'd be having a much different conversation. As it stands, a .pth file implements something that fits either PEP's definition. So I can only assume that you have a much more restrictive definition in mind.
But at this point we're just arguing all of the points that were covered in the PEP discussion. And we're not going to end up at any different conclusion. Even if we declared PEP 660 a failure, and abandoned it, we'd still only have symlinks, import hooks and .pth files as implementation strategies, we'd still not have a formal definition of an "editable install", and setuptools wouldn't be any more able to implement their ideal "not broken" approach to editable installs than they currently are.
[^1]: Whatever that means, as there's no actual definition of what an editable install is apart from "what setup.py develop did", which is a .pth file with all its warts and limitations.

In my opinion, PEP 660 isn't equipped to handle anything this intricate

It's not clear to me that any strategy is perfect here.

I don't think that any of the strategies mentioned so far is perfect either.
When I said that symlinking would work, I meant that it would have the intended outcome. That it can't be relied on on Windows makes it a lot less than "perfect".
When I said PEP 660 isn't equipped to handle anything this intricate, I meant that the delivery medium for PEP 660 is the wheel and pre-installing packages at some unspecified location on disk, and presumably not recording them in the distribution's metadata, is very much not something that the PEP invites.

Somehow I haven't stated this already: As much as I agree that the strict mode will be better than the status quo in terms of a UX, I don't think that coupling the changeover with PEP 660 is a good idea.

If there were, setuptools wouldn't even have had to make this choice at all, and front-ends could choose to fix the bug or present different installation options. They didn't, and so setuptools is forced to make a choice of doing it one way or the other.

Sure. Then frontends would need to make the choice, or expose the users to a mechanism to pick on their end.
And they'd need to be mindful of backwards compatibility concerns if they made the change that you want to force setuptools to make, in the same manner that setuptools needs to right now. I can tell you that pip would not do this work, and just have the pth based approach as the default for quite a while.

It isn't an "issue" with the PEP, it's a consequence of the fact that you absolutely want to change behaviours in the initial implementation. You know that making drastic, backwards incompatible changes without putting effort to reduce the transition costs/churn is how you burn goodwill with users. None of the proposals magically avoid the backwards compatibility concerns in any way; they shift who has to do that.

Surely passing --no-isolation and pre-installing setuptools would work?

Yes, if you also manage the rest of the build-time dependencies of the project. It would be a viable workaround, but certainly not something that I'd consider to be "smooth".

Surely any users who are installing a package can edit their own pyproject.toml to add version caps to setuptools, no?

Use an older version if the newer version breaks things for you, is certainly an option. I'm not sure I'm quite on board with the idea of having users pin their setuptools versions in pyproject.toml, but... sure. It's strictly worse than providing a knob to only change the editable behaviour.

The people in favor of PEP 660 seemed to think that "edit config files in the package" was an acceptable UI for end users, and if you are actually relying on the old behavior then of course you should modify your build dependencies to reflect that.

I don't know who thought that was an acceptable UI

+1

the options themselves are specific to the backend

Right now, setuptools is the only backend that wants to change how editable installs work.

I'm not even sure that all front-ends have a way to pass options via that mechanism.

Only one popular option does not: pip. As @pfmoore said:

I'd be happy to support improving pip's UI for passing config settings to the backend, if that turns out to be needed to make this work

The point is that we have to go outside of the standard to allow end-users to configure this if it's possible at all.

No? Unless you want to standardise the name of the config setting that only setuptools is going to use, I don't see what else can be done TBH. Or if you want to have a separate dedicated option, I still don't think that has much value.
As far as I can tell, exactly 1 backend is considering implementing something other than the existing pth file mechanism. Heck, exactly one backend maintainer wants to implement something other than the existing pth file mechanism: @pganssle.
I don't see how standardisation would have had much value here.

As far as I can tell, exactly 1 backend is considering implementing something other than the existing pth file mechanism. Heck, exactly one backend maintainer wants to implement something other than the existing pth file mechanism: @pganssle.

PEP 660 did not standardise the nature of "editableness".  If backends are only expected to use .pth files then the PEP should have standardised (path-only) .pth files and discussions like this one would have been avoided.  pip doesn't care about anything else, other backends don't care about anything else, so why bother with anything else?

PEP 660 did not standardise the nature of "editableness".

Nowhere in any of the discussions on editable installs, did we achieve any sort of consensus on what an "editable install" should be. People seemed comfortable with leaving it implementation defined. Was that wrong? Maybe as a community we should be more strict over how much implementation defined behaviour we're willing to accept in PEPs?

If backends are only expected to use .pth files then the PEP should have standardised (path-only) .pth files and discussions like this one would have been avoided. pip doesn't care about anything else, other backends don't care about anything else, so why bother with anything else?

Maybe. But hindsight is easy. Why did no-one suggest that at the time? Both PEP 660 and PEP 662 left the definition implementation-defined, and a huge amount of the discussion was around ways of implementing "better" editable installs. Would anyone have got consensus if they'd said "let's just standardise a way of injecting a .pth file, like setup.py develop currently does"? I don't know.
Given that PEP 660 is currently still provisional[^1], we could propose a change to define editable installs precisely, requiring a .pth based approach. So if you genuinely believe that's the right thing to do, I suggest you do that. If nothing else, it might help pin down a consensus on exactly what the packaging community does want.
[^1]: But be quick, the vote to make it final is in progress right now 🙂

PEP 660 did not standardise the nature of "editableness". If backends are only expected to use .pth files then the PEP should have standardised (path-only) .pth files and discussions like this one would have been avoided.

Would anyone have got consensus if they'd said "let's just standardise a way of injecting a .pth file, like setup.py develop currently does"? I don't know.

I remember this coming up in between the discussions but got quickly discarded as too restrictive. I for one would be against such a narrow scoped definition.  Note I'm not a backend maintainer though.

Was that wrong?

I don't know if that was wrong. But maybe we should show some lenience if that's a door we intentionally left open instead of treating setuptools like an anomaly because they are thinking about trying something different.

So if you genuinely believe that's the right thing to do [...]

Please re-read my response in context.

Ah, apologies, I did indeed misread your comment.

I no longer have the motivation to work on this given the .pth approach isn't acceptable. Figuring out how to basically rewrite the entire editable install mechanism as my first contribution to setuptools is just not feasible or a good idea.


Error deploying with TensorFlowModel

Hi,
I tried the deployment part with the EfficientDet model from tf2 object detection api directly without fine tuning it, and whenever i try to call model.deploy() it takes a long time and then gives me the following error:
UnexpectedStatusException: Error hosting endpoint tf2-object-detection-2022-05-28-10-46-50-583: Failed. Reason:
The customer:primary container for production variant AllTraffic did not pass the ping health check.
Please check CloudWatch logs for this endpoint..

Q: Can i use the tf2 object detection api model directly without tuning it with sagemaker.tensorflow.serving.Model.TensorFlowModel ?
Thanks in advance!

so the problem was the folder structure of the pretrained model...
you have to name the top file as a number so that it is recognized as the model version
some_name
    |__ Some positive number that represents version (For eg: 1)
            |__ saved_model.pb
            |__ variables
                    |__ (Non empty)

that should solve it


Error in scipy.signal.periodogram example

The example code for sciipy.signal.periodogram at https://docs.scipy.org/doc/scipy-0.19.1/reference/generated/scipy.signal.periodogram.html contains an error:
According to the text
>>> np.mean(Pxx_den[256:])
0.0018156616014838548

Should return the noise power of the signal, i.e. 0.001. This is not the case because in Pxx_den[256:] the signal peak at 1234 Hz is included. Correctly, the statement should be something like
>>> np.mean(Pxx_den[10000:])
0.00099830549215597321

Reproducing code example:
np.mean(Pxx_den[256:])

Scipy/Numpy/Python version information:
('0.18.1', '1.11.3', sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0))

Do you have time to make a PR @thuehlinger?

The suggested np.mean(Pxx_den[10000:]) converges to 0.002 not 0.001 (both for me locally and in gh-7557). So a factor 2 is missing in the explanation.

fixed by gh-7610


Update ingress.md version

Ingress version change to Kubernetes v1.1 [beta]

This PR is not correct and lacks a description for proper review. Given the influx of spam PRs we've seen with Hacktoberfest, I'm going to close. Feel free to reopen with a clear description of the change if done in error. Thanks!
/close


Implement the Lucas-V ("vpsp") check in the Lucas test

Baillie et al[^Baillie2021] introduce another condition that can be checked in the Lucas test (Eq. 2, and later Def. 7). They report it leading to very few false positives compared to the original Lucas part of the Baillie-PSW test. Need to see if implementing it slows down the test significantly; if it does, we can make it optional.
Also it kind of resembles the already implemented "extra strong check".
[^Baillie2021]: R. Baillie, A. Fiori, S. S. Wagstaff,
"Strengthening the Baillie-PSW primality test",
Math. Comp. 90 1931-1955 (2021),
DOI: 10.1090/mcom/3616

Added in 3ce6cf85e4d1b9cdc174f2f5827693619c7c7b51

Actually, in my tests Lucas-V seems to be a little faster in general. I assume it has something to do with the relative cost of operations (multiplication, inversion, Montgomery conversion) in Mathematica compared to the Rust library I'm using. It may even be sped up more by implementing some optimizations mentioned in #2.

@ValZapod , I just noticed that in the link you posted they didn't find any pseudoprimes for Lucas-V under 10 million, but there should be one - 913 (see the paper referenced in the beginning of this issue). I wonder what is causing it.

The second item does not seem to be particularly useful; the single modular inverse we perform to check for U = 0 is fast enough, and dividing by 2 in Montgomery space (which is required to employ the Baillie et all approach) is quite inconvenient.

This?

Yes, this is the U check I'm referring to. I think I stopped at just implementing the V check out of curiosity because I was more concerned with following the FIPS standard. But I see that later in the paper they advocate for combining U and V checks. This would make the test slower. The item 1 from #2 can be revisited if there's some efficient way to divide by 2 in Montgomery representation.

Hm, actually it seems that just the division by 2 in the Montgomery form should work fine. So #2 can definitely be revisited.


New Customization

Problem description

It will be better if more of the widgets can be customized individually with more options.
Expected behavior
I will like to be able to customize the following widgets with the following:
TextInput - border
TextView - text-shadow,more font-type like open-sans,etc
All - background-gradient,padding,margin,border, box-shadow etc
THEME
There should be more theme color type specified for custom theme styling. E.g. setting default text primary color, using gradient colors, etc
I also noticed that some widget doesn't use theme color by default, e.g. button which is not proper. If the tab widget can use theme color, every other widget should too unless other color is specificied in the the widget.
NOTE: color is both background and text.
The video widget doesn't work properly with audio, if its possible, a standalone audio widget is better.
Environment

Tabris.js version: 3.0

Code snippet

TextInput - border

http://docs.tabris.com/latest/api/TextInput.html#bordercolor

TextView - text-shadow,more font-type like open-sans,etc

Shadow could be a good addition, but you can already achieve this by cloning the element and offseting it by 1px
Fonts are already settable and you can load custom fonts

All - background-gradient,

Already possible: set the background

padding/margin

Already possible: padding and layout

border

For what type of widgets?  On some (TextInput, Button) it's already supported.  In some other cases it might not be needed.

box-shadow

Already possible; set the elevation

Themes

See my suggestion here

The video widget doesn't work properly with audio, if its possible, a standalone audio widget is better.

I've used cordova-plugin-media and it worked great.

Good additions here and thanks @cookieguru for chiming in an all the features already available. :)
One area we want to improve is the styling capabilities of the TextInput with its border and message hint appearance.

Really version 3 is lots much more fun with new stuffs and lots of better customization


Missing docs

When executing this code shows a link for the error E0554. But there is no documentation for this and others errors after E0522.

New issue in the Rust site repository https://github.com/rust-lang/rust-www/issues/495


failed to install using pip on ubuntu16 under anaconda

 pip install dlib
Collecting dlib
  Using cached https://files.pythonhosted.org/packages/35/8d/e4ddf60452e2fb1ce3164f774e68968b3f110f1cb4cd353235d56875799e/dlib-19.16.0.tar.gz
Building wheels for collected packages: dlib
  Running setup.py bdist_wheel for dlib ... error
  Complete output from command /home/rjn/anaconda3/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-v2keat6o/dlib/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-1mx47y1d --python-tag cp36:
  running bdist_wheel
  running build
  running build_py
  package init file 'dlib/__init__.py' not found (or not a regular file)
  running build_ext
  Building extension for Python 3.6.8 |Anaconda custom (64-bit)| (default, Dec 30 2018, 01:22:34)
  Invoking CMake setup: 'cmake /tmp/pip-install-v2keat6o/dlib/tools/python -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/tmp/pip-install-v2keat6o/dlib/build/lib.linux-x86_64-3.6 -DPYTHON_EXECUTABLE=/home/rjn/anaconda3/bin/python -DCMAKE_BUILD_TYPE=Release'
  -- The C compiler identification is GNU 5.5.0
  -- The CXX compiler identification is GNU 5.5.0
  -- Check for working C compiler: /home/linuxbrew/.linuxbrew/bin/cc
  -- Check for working C compiler: /home/linuxbrew/.linuxbrew/bin/cc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Check for working CXX compiler: /home/linuxbrew/.linuxbrew/bin/c++
  -- Check for working CXX compiler: /home/linuxbrew/.linuxbrew/bin/c++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found PythonInterp: /home/rjn/anaconda3/bin/python (found version "3.6.8")
  -- Found PythonLibs: /home/rjn/anaconda3/lib/libpython3.6m.so
  -- Performing Test HAS_CPP14_FLAG
  -- Performing Test HAS_CPP14_FLAG - Success
  -- pybind11 v2.2.2
  -- Using CMake version: 3.5.1
  -- Compiling dlib version: 19.16.0
  -- SSE4 instructions can be executed by the host processor.
  -- AVX instructions can be executed by the host processor.
  -- Enabling AVX instructions
  -- Looking for pthread.h
  -- Looking for pthread.h - found
  -- Looking for pthread_create
  -- Looking for pthread_create - not found
  -- Looking for pthread_create in pthreads
  -- Looking for pthread_create in pthreads - not found
  -- Looking for pthread_create in pthread
  -- Looking for pthread_create in pthread - found
  -- Found Threads: TRUE
  -- Looking for XOpenDisplay in /home/linuxbrew/.linuxbrew/lib/libX11.so;/home/linuxbrew/.linuxbrew/lib/libXext.so
  -- Looking for XOpenDisplay in /home/linuxbrew/.linuxbrew/lib/libX11.so;/home/linuxbrew/.linuxbrew/lib/libXext.so - found
  -- Looking for gethostbyname
  -- Looking for gethostbyname - found
  -- Looking for connect
  -- Looking for connect - found
  -- Looking for remove
  -- Looking for remove - found
  -- Looking for shmat
  -- Looking for shmat - found
  -- Looking for IceConnectionNumber in ICE
  -- Looking for IceConnectionNumber in ICE - found
  -- Found X11: /home/linuxbrew/.linuxbrew/lib/libX11.so
  -- Searching for BLAS and LAPACK
  -- Searching for BLAS and LAPACK
  -- Found PkgConfig: /home/linuxbrew/.linuxbrew/bin/pkg-config (found version "0.29.2")
  -- Checking for module 'cblas'
  --   No package 'cblas' found
  -- Checking for module 'lapack'
  --   No package 'lapack' found
  -- Looking for sys/types.h
  -- Looking for sys/types.h - found
  -- Looking for stdint.h
  -- Looking for stdint.h - found
  -- Looking for stddef.h
  -- Looking for stddef.h - found
  -- Check size of void*
  -- Check size of void* - done
  -- Found Intel MKL BLAS/LAPACK library
  -- Looking for sgesv
  -- Looking for sgesv - found
  -- Looking for sgesv_
  -- Looking for sgesv_ - found
  -- Found CUDA: /usr/local/cuda (found suitable version "10.1", minimum required is "7.5")
  -- Looking for cuDNN install...
  -- Found cuDNN: /usr/lib/x86_64-linux-gnu/libcudnn.so
  -- Building a CUDA test project to see if your compiler is compatible with CUDA...
  -- Checking if you have the right version of cuDNN installed.
  -- Enabling CUDA support for dlib.  DLIB WILL USE CUDA
  -- C++11 activated.
  CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
  Please set them or make sure they are set and tested correctly in the CMake files:
  cusolver (ADVANCED)
      linked by target "dlib" in directory /tmp/pip-install-v2keat6o/dlib/dlib

  -- Configuring incomplete, errors occurred!
  See also "/tmp/pip-install-v2keat6o/dlib/build/temp.linux-x86_64-3.6/CMakeFiles/CMakeOutput.log".
  See also "/tmp/pip-install-v2keat6o/dlib/build/temp.linux-x86_64-3.6/CMakeFiles/CMakeError.log".
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/tmp/pip-install-v2keat6o/dlib/setup.py", line 257, in <module>
      'Topic :: Software Development',
    File "/home/rjn/anaconda3/lib/python3.6/site-packages/setuptools/__init__.py", line 140, in setup
      return distutils.core.setup(**attrs)
    File "/home/rjn/anaconda3/lib/python3.6/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/home/rjn/anaconda3/lib/python3.6/distutils/dist.py", line 955, in run_commands
      self.run_command(cmd)
    File "/home/rjn/anaconda3/lib/python3.6/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/home/rjn/anaconda3/lib/python3.6/site-packages/wheel/bdist_wheel.py", line 202, in run
      self.run_command('build')
    File "/home/rjn/anaconda3/lib/python3.6/distutils/cmd.py", line 313, in run_command
      self.distribution.run_command(command)
    File "/home/rjn/anaconda3/lib/python3.6/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/home/rjn/anaconda3/lib/python3.6/distutils/command/build.py", line 135, in run
      self.run_command(cmd_name)
    File "/home/rjn/anaconda3/lib/python3.6/distutils/cmd.py", line 313, in run_command
      self.distribution.run_command(command)
    File "/home/rjn/anaconda3/lib/python3.6/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/tmp/pip-install-v2keat6o/dlib/setup.py", line 133, in run
      self.build_extension(ext)
    File "/tmp/pip-install-v2keat6o/dlib/setup.py", line 170, in build_extension
      subprocess.check_call(cmake_setup, cwd=build_folder)
    File "/home/rjn/anaconda3/lib/python3.6/subprocess.py", line 311, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['cmake', '/tmp/pip-install-v2keat6o/dlib/tools/python', '-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/tmp/pip-install-v2keat6o/dlib/build/lib.linux-x86_64-3.6', '-DPYTHON_EXECUTABLE=/home/rjn/anaconda3/bin/python', '-DCMAKE_BUILD_TYPE=Release']' returned non-zero exit status 1.

  ----------------------------------------
  Failed building wheel for dlib

Cuda 10.1 broke their install and cmake doesn't find it.  Try the latest dlib from github, I added a workaround for this issue.

@rnunziata, maybe you can install cusolver development lib and header files as an attempt.


Thumbnailator

Is your feature request related to a problem? Please describe.
Thumbnailator's fluent interface can be used to perform fairly complicated thumbnail processing task in one simple step.
Describe the solution you'd like
creating JPEG thumbnails of image files in a directory, all resized to a maximum dimension of 640 pixels by 480 pixels while preserving the aspect ratio of the original image can be performed
Describe alternatives you've considered
No response
Additional context
Assign this issue to me under GSSOC'23
Code of Conduct

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

@shraddha761 - you can go ahead! We are assigning you 21 days for this project, after which it will be assigned to someone else if not completed. All the best!
Name the file as: algorithm_dataset.ipynb and link it in the readme of the labeled directory as algorithm - dataset.


Allow disabling analytics using an environment variable (Node.js)

Offer a way to completely shut down analytics by using an environment variable. This should only be available on Node.js clients

Closing stale issues


Made all installer types lowercase during show.

[x] Have you signed the Contributor License Agreement?
[x] Are you working against an Issue?

Resolves #1685.
Microsoft Reviewers: Open in CodeFlow

/azp run

This will change the value returned in com api, but maybe it's ok.

I didn't think about that, although wouldn't the consumers of the COM API probably have the expectation that this value wasn't capitalized oddly?

/azp run

/azp run

The problem is just that if things change, then existing code can break.  The good thing is that this change isn't likely to impact anyone.  It would only affect getting the installer type of installed packages as far as I saw, and I don't know if anyone is even doing that right now.


Misc updates

the embeddings is not working

This line is belong to deprecated models, As far as I know, it should new line does not effect of 002, and 003; @logankilpatrick plz ping @ted-at-openai or @arvind-neelakantan
    # replace newlines, which can negatively affect performance.
     text = text.replace("\n", " ")

https://github.com/openai/openai-cookbook/blob/c1bd61f944d46e3539b4a136e4273df79b1b7eed/examples/utils/embeddings_utils.py#L20

guys links need to be updated in the docs on here
https://platform.openai.com/docs/guides/embeddings/use-cases#:~:text=Code search using-,embeddings,-Code_search.ipynb


Rug updates: March, 2021

After the fix to #2220 landed, I went to revert a workaround for it that I'd put in Rug some time ago, and I figured I'd take care of brimsec/rug#205 while I was at it. However, in the act of re-running Rug with current zq to verify my updated reference results, I found a few other things had broken in the meantime that also caused new Rug failures. Specifically:

#2244
#2253
#2259

I'll hold on to this issue and keep re-testing and adding more blockers as necessary until we have Rug running green consistently again with our common/big data sets. Weather permitting, I may then move on to have Rug triggered to run after each zq commit (as we've discussed before) so we can start catching these failures as they happen.

I've attached valid Rug output showing that all tests are running ok for all data sets as of zed commit 79c4047.
output.txt
I'm planning to run this frequently on my laptop to make sure we don't regress. When we have something like the cloud service again we can revisit running the tests against that as part of our CI.


support more nodes than there are AZs defined

what

Allows not defining availability_zones
Can create more nodes than you have defined AZs (once AWS provider is fixed https://github.com/hashicorp/terraform-provider-aws/issues/14070#issuecomment-771079450)

why

availability_zones parameter shouldn't be required.
You might want to define the AZs you use and have more nodes than AZs, e.g. use two AZs and 4 nodes

references

https://github.com/hashicorp/terraform-provider-aws/issues/14070#issuecomment-771079450
Similar fix was done to memcached module https://github.com/cloudposse/terraform-aws-elasticache-memcached/pull/28
Closes #63

/test all

/test all

/rebuild readme

/rebuild-readme

/test readme

/test all

@Mergifyio update

/test all

@SweetOps @gusse , this still fails for me. How we do check if this test worked?

@hawkesnhawkesn  ^^


METRON-2172 Solr Updates Not Tested in Integration Test

The SolrUpdateIntegrationTest is not testing that the SolrDao can update and retrieve values. This fix is similar to what was done for Elasticsearch in #1451.
This replaces #1454 which was a more involved refactor that fixed some issues with code duplication and provided additional unit tests.  I am going to break-off just the bare minimum of what we need to fix the broken tests, rather than fix and refactor in the same PR.
What?
This gap in the integration test is hiding a couple bugs.

A timestamp is not being populated in the documents returned from Solr.

The integration test is not accounting for the fact that comments are serialized differently when written to Solr versus Elasticsearch.  When comments are written to Solr, they are serialized as a list of JSON strings.  When comments are written to Elasticsearch, they are serialized as a list of maps.

Why?
These problems arise because of the way the test is setup.  Instead of directly testing a SolrDao this test runs against a MultiIndexDao initialized with both a SolrDao and an HBaseDao. On retrievals the MultIndexDao will return the document from whichever index responds first.
With the current test setup, the underlying SolrDao will never retrieve the document that the test case is expecting.  In all cases where the test passes, the document is actually being returned from the HBaseDao which is actually just interacting with a mock backend.  The test needs to actually test that we can update and retrieve documents from Elasticsearch.
Changes

The SolrUpdateIntegrationTest was changed so that it specifically tests a SolrDao.

The UpdateIntegrationTest was changed so that it can handle comments stored as either strings or maps.  This allows the same integration tests to continue to work when run against either Solr or Elasticsearch.

Acceptance Testing

[x] Validate against Elasticsearch.

Spin-up Full Dev with Elasticsearch running.
Ensure alerts are visible in the Alerts UI.
Add a comment to an alert.

[x] Validate against Solr.

Spin-up Full Dev with Solr running.
Ensure alerts are visible in the Alerts UI.
Add a comment to an alert.

Pull Request Checklist

[x] Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
[x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
[x] Has your PR been rebased against the latest commit within the target branch (typically master)?
[x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?
[x] Have you included steps or a guide to how the change may be verified and tested manually?
[x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
[x] Have you written or updated unit tests and or integration tests to verify your changes?
[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[x] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

Looks pretty good. A couple small nits and I think this is good to go.

+1 thanks @nickwallen


what does shim repo mean?

I wonder what shim repo mean? I do not find any introduction, can anyone explain for me?
for instance, what's the difference between highlightjs here and this one? thanks

It's a helper repository, to make it easier to consume into different package management systems. You could likely use highlightjs straight from the source, without needing this.

@RobLoach
thanks for your reply. The shim one is compatiable to multiple package management systems, such as AMD, commonjs, broswerify and so on? Can I understand like this?
another question, why the shim one(514kb) is much much larger than the normal one(30~40kb)? thanks in advance!

Might include some addons to Highlight? Unsure. Feel free to submit a PR to update/fix as needed.


Query by hostname

This is a simple, but very convenient feature borrowed from WeaveDNS.
Docker already has built-in support for specifying a container's hostname via the -h option. Compose supports a corresponding hostname property.
These options will set the HOSTNAME environment variable, which in turn will notify the container about what its own hostname is.
By enabling dnsdock to automatically register DNS entries matching the hostname setting, the DNS server and the container itself can be configured simultaneously.
$ docker run -e DNSDOCK_ALIAS=myservice.docker -h myservice.docker --rm ubuntu hostname
myservice.docker

becomes
$ docker run -h myservice.docker --rm ubuntu hostname
myservice.docker

Tests are failing.
I'm also not sure if this is what everyone want. Maybe we should provide a way to opt-out (with another env maybe).

Another observation is that this code doesn't seem to support the case where the container hostname is outside of the dnsdock domain (unlike aliases, which can be outside the dnsdock domain). To do so, you'd need to add logic similar to the s.mux.HandleFunc and s.mux.HandleRemove lines in AddService and RemoveService.

Closing this PR as no follow up can be found


[#11274] record real request path as an annotation, no normalization.

Fix #11274.
UI v2:

UI v3:

Rebased on the current master.


Added LegacyRepositoryClient

I found that I needed this for local development of a Bot, so I went ahead and polished it up.
This introduces LegacyRepositoryClient -- an API client with the JavaScript interface of the original Bot repo.
Use cases:

Local development of bots
Migration pathway away from original Bot repo to API clients

Along the way, I tweaked some of the MedplumClient API to align with the upcoming API review:

create -> createResource
read -> readResource
update -> updateResource
patch -> patchResource

Coverage increased (+0.009%) to 95.241% when pulling 806ab43a1b5fb459928d946655071b240dd60151 on cody-legacy-repo-client into f0aa2a52c354a269a7eabfddc98f4e65c2654d6c on main.


Newlines overwrite link text when inserting a link

How to reproduce:

write a sentence
press Shift+Alt+Left
press Link button
choose a link
see that the text is not highlighted anymore
press Enter
newline symbol overwrote the link sentence

Moving this to https://github.com/springload/draftail/issues/108 as the issue is not specific to the editor being within Wagtail.


AgentExcecutor Chains Are Deleting the Run Name

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain.js documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain.js rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
  const agentExecutor = new AgentExecutor({
    agent,
    tools,
  }).withConfig({ runName: 'Hi test!' })

 const eventStream = agentExecutor.streamEvents(params, {
      version: 'v1',
 })

Error Message and Stack Trace (if applicable)
No response
Description
I've dug a bit though the source, and have found the following:
In the patchConfig.js file, we have
        /**
         * If we're replacing callbacks we need to unset runName
         * since that should apply only to the same run as the original callbacks
         */
        delete newConfig.runName;

which is where my Hi test goes to die!
Interestingly, the name parameter is right in the actual stream events. I've tried to hit the Langsmith endpoint directly to set the run name, but that messes up other things (the output never gets filled out...?)
The name that ultimately gets logged to Langsmith is AgentExecutor.
System Info
└─ langchain@npm:0.1.36
   ├─ Instances: 1
   ├─ Version: 0.1.36
   │
   └─ Dependencies
      ├─ @anthropic-ai/sdk@npm:^0.9.1 → npm:0.9.1
      ├─ @langchain/community@npm:~0.0.47 → npm:0.0.49
      ├─ @langchain/core@npm:~0.1.60 → npm:0.1.62
      ├─ @langchain/openai@npm:~0.0.28 → npm:0.0.28
      ├─ @langchain/textsplitters@npm:~0.0.0 → npm:0.0.0
      ├─ binary-extensions@npm:^2.2.0 → npm:2.2.0
      ├─ js-tiktoken@npm:^1.0.7 → npm:1.0.10
      ├─ js-yaml@npm:^4.1.0 → npm:4.1.0
      ├─ jsonpointer@npm:^5.0.1 → npm:5.0.1
      ├─ langchainhub@npm:~0.0.8 → npm:0.0.8
      ├─ langsmith@npm:~0.1.7 → npm:0.1.22
      ├─ ml-distance@npm:^4.0.0 → npm:4.0.1
      ├─ openapi-types@npm:^12.1.3 → npm:12.1.3
      ├─ p-retry@npm:4 → npm:4.6.2
      ├─ uuid@npm:^9.0.0 → npm:9.0.1
      ├─ yaml@npm:^2.2.1 → npm:2.4.1
      ├─ zod-to-json-schema@npm:^3.22.3 → npm:3.23.0
      └─ zod@npm:^3.22.4 → npm:3.23.7

Thanks for flagging this! Very strange error, it looks like it only happens when calling .stream or .streamEvents
I'll look into this and push a fix asap!


search area for tag

Trying to locate nodes within a radius or rect that contain an Osm tag such as fire hydrant https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant
I've tried creating a RouterDb from ontario-latest.osm.pbf and then exporting a geojson around a known lat-long using GetGeoJsonAround with no edges, yes vertices, yes Profile details.
In this case none of the vertices have any tags. should tags be available in the geojson, or am I looking in the wrong location, or is it simply not available with itinero?

This is a routing library, the router only keeps tags defined in the profile when it's built, instead of doing that though just use the linestring and find what intersects it from an OSM using something like http://www.osmsharp.com/


Module loses some methods and propreties when imported into another python script

From @gtalarico on November 14, 2016 0:30
I have been struggling with this for while, and haven't been able to find any information on it.
I understand this might not be enough information for you to be able to help, so please feel free to close it.
I have no idea, if this is a IronPython bug, or something about imports in Python I am not aware of.
I also can't provide a good repro case, since this assembly will not load outside the program environment (Autodesk Revit), so will provide a generic equivalent case below.
Any information/ideas on what could be causing this would be greatly appreciated.
File1.py
import clr
clr.AddReference('RevitAPI')          # Contains Autodesk.Revit.DB namespace
from Autodesk.Revit import DB
DB.Element.Name                         # OK.
DB.Element.Name.GetValue()        # OK: Method exists. As Expected

File2.py
from File1 import DB
DB.Element.Name                         # OK
DB.Element.Name.GetValue()        # **Method DOES NOT Exist**, get an Attribute Error is raised.
from Autodesk.Revit import DB    # Re-import the same namespace again
DB.Element.Name.GetValue()        # OK:  Method Exists

Copied from original issue: IronLanguages/main#1540

Should File2.py have "from File1 import DB"?
On Sun, Nov 13, 2016 at 5:30 PM Gui Talarico<EMAIL_ADDRESS>wrote:

I have been struggling with this for while, and haven't been able to find
any information on it.
I understand this might not be enough information for you to be able to
help, so please feel free to close it.
I have no idea, if this is a IronPython bug, or something about imports in
Python I am not aware of.
I also can't provide a good repro case, since this assembly will not load
outside the program environment (Autodesk Revit), so will provide a generic
equivalent case below.
Any information/ideas on what could be causing this would be greatly
appreciated.
File1.py
import clr
clr.AddReference('RevitAPI')          # Contains Autodesk.Revit.DB namespace
from Autodesk.Revit import DBDB.Element.Name                         # OK.
DB.Element.Name.GetValue()        # OK: Method exists. As Expected
File2.py
from File2 import DBDB.Element.Name                         # OK
DB.Element.Name.GetValue()        # Method DOES NOT Exist, get an Attribute Error is raised.
from Autodesk.Revit import DB    # Re-import the same namespace again
DB.Element.Name.GetValue()        # OK:  Method Exists
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/IronLanguages/main/issues/1540, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADaP4Pp1GAbgPF8TWqrlfFRyf-jbzksks5q96u3gaJpZM4Kw26Q
.

From @gtalarico on November 14, 2016 0:53
Thanks slide, sorry, typo in example.
I have revised the code sample.
PS: cross posted this on Stack Overflow, I will post back and close If I get a response.
http://stackoverflow.com/questions/40580471/net-assembly-loses-some-methods-when-imported-from-one-python-file-into-another

From @andygraham on November 14, 2016 18:56
I don't know if this is related to the above or is a different feature concerning the mapping of .NET Object class to the Python object class.
I tried the same but using Form from System.Windows.Form and found four methods missing. Interestingly they seem to be four base methods  of the .NET Object class. They are visible in the Form class in file1 but missing in the imported Form class in file2.
Equals
GetHashCode
GetType
ReferenceEquals
Doing it with Int16 includes Equals and GetHashCode but loses
GetType
MemberwiseClone
ReferenceEquals
different but again base methods from Object.
Trying it with various .NET classes I get various numbers of different methods missing. There seems no consistency except they always seem to be the Object base methods.

From @gtalarico on November 20, 2016 0:2
@slide can you reproduce this as well?

From @PMoureu on December 7, 2016 2:0
This may be linked to clr, and how it handles the references to the DLL used in each cases.
In each 2nd file, all references come back just by adding :
import clr
Same results if you import another namespace from the assembly like
from Autodesk.Revit.UI import TaskDialog
or
from System.Windows.Forms import Label
"Such context change is per-python-module" https://blogs.msdn.microsoft.com/haibo_luo/2007/09/

I can look into this next week.

From @andygraham on November 20, 2016 9:35
Here is the code I used to test it - might save you a few minutes!
Test.zip
produce it. Run file2.py

From @andygraham on December 7, 2016 8:51
That's interesting! I didn't think of trying that - though I probably should have :(.  I would have expected all the .NET methods or none to be available without clr imported. I wonder why only a random few go missing!

Just wanted to post a work-around I found for my specific case where the GetValue / SetValue are missing. The internal dunder method still works:
>>> DB.Element.Name.GetValue(self._revit_object)
'getset_descriptor' object has no attribute 'GetValue'
>>> DB.Element.Name.__get__(self._revit_object)
ABC


Some python and notebook versions of examples have diverged

Describe the bug
Not sure it is the case for all examples, but for the mortgage ETL + XGBoost example there are some non-trivial discrepancies.   Example:
python script has udfs:  https://github.com/NVIDIA/spark-rapids-examples/blob/main/examples/XGBoost-Examples/mortgage/python/com/nvidia/spark/examples/mortgage/etl.py#L22-L23
while the notebook(s) implement these using Spark SQL directly:
https://github.com/NVIDIA/spark-rapids-examples/blob/main/examples/XGBoost-Examples/mortgage/notebooks/python/MortgageETL.ipynb?short_path=2af22cf#L454-L478
There are some other differences.    Looks like the scripts may be lagging the notebooks.
Steps/Code to reproduce bug
N/A
Expected behavior
Notebooks and python script versions should ideally be aligned (or at least documented why they don't).
Environment details (please complete the following information)
N/A

@nvliyuan Do you remember who wrote these examples? I can't recall the reason, but there should be.

Yes, the same example with different implementations should keep the same logic, will draft a pr to fix it.


tf2 version

Tensorflow2 version of the lanczos algorithm for hessian approximation.

Thank you!
This PR was thoroughly reviewed internally, so merging without further comments.


BUG: jupyter bash variable

aws not set in jupyter terminal

closed via https://github.com/kingjr/aws/commit/8b349a8387d29726b08f4ad95aeabbc7bb1b6918


Fix typo in "sign-on"

Change "sing" to "sign".

@jdtw : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


mpi executable crashes with segmentation fault

I'm using the following commands to build the mpi executable:
nvcc -forward-unknown-to-host-compiler -DUSE_NVTX -isystem=/usr/local/cuda/include --generate-code=arch=compute_61,code=[compute_61,sm_61] -Xptxas --optimize-float-atomics --std=c++14 -c jacobi_kernels.cu -o jacobi_kernels.cu.o
c++ -DSKIP_CUDA_AWARENESS_CHECK -DUSE_NVTX -isystem /usr/local/cuda/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -fopenmp -g -pthread -std=c++14 -o jacobi.cpp.o -c jacobi.cpp
c++ -pthread jacobi.cpp.o jacobi_kernels.cu.o -o mpi -L/usr/local/cuda/targets/x86_64-linux/lib/stubs /usr/local/cuda/lib64/libnvToolsExt.so /usr/local/cuda/lib64/libcudart.so /usr/lib/x86_64-linux-gnu/libcuda.so /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so /usr/lib/gcc/x86_64-linux-gnu/10/libgomp.so /usr/lib/x86_64-linux-gnu/libpthread.so -lcudadevrt -lcudart_static -lrt -lpthread -ldl

The main difference from your Makefile is that jacobi.cpp is compiled directly with the host-side C++ compiler, not the mpicxx wrappers. But... this is supposed to be legit, right? These lines are adaptations of what CMake generates.
Anyway, it does get built, and runs, but at the end of the first 1000 iterations, has a segmentation fault at:
        MPI_CALL(MPI_Sendrecv(a_new + iy_start * nx, nx, MPI_REAL_TYPE, top, 0,
                              a_new + (iy_end * nx), nx, MPI_REAL_TYPE, bottom, 0, MPI_COMM_WORLD,
                              MPI_STATUS_IGNORE));

With the stack being:
__memmove_avx_unaligned_erms 0x00007f03d477fb12
<unknown> 0x00007f03d0252280
mca_pml_ob1_recv_request_get_frag 0x00007f03d003fcbf
mca_pml_ob1_recv_request_progress_rget 0x00007f03d0040106
<unknown> 0x00007f03d003ba2b
<unknown> 0x00007f03d003bcc0
<unknown> 0x00007f03d0252983
mca_pml_ob1_send_request_start_rdma 0x00007f03d0048131
mca_pml_ob1_send 0x00007f03d00389ef
PMPI_Sendrecv 0x00007f03d4da3ece
main jacobi.cpp:239
__libc_start_main 0x00007f03d4643d0a
_start 0x000055becffc4d8a

@eyalroz does it work if you use the mpi compiler wrapper mpicxx? You can make this work by using the host-side C++ compiler but need to be careful to set the right preprocessor defines and include paths for your MPI. Something mpicxx does for you. For OpenMPI you can use the --showme command line flag of the compiler wrappers to check. See e.g. the man page of mpicxx: https://www.open-mpi.org/doc/current/man1/mpicxx.1.php

I also get this same behavior if I make the functions launch_initialize_boundaries() and launch_jacobi_kernel() do nothing, so that I don't use NVCC at all.

I also get this same behavior if I make the functions launch_initialize_boundaries() and launch_jacobi_kernel() do nothing, so that I don't use NVCC at all.

My comment was not about NVCC. It was about the need to use mpicxx as otherwise you can easily get an include path or define wrong.

Oh, an important point! I should also mention I don't use mpirun, I just run the executables directly. - and if I do use mpirun -np 1 or mpirun -np 2, there's no crash.

OK than that is the issue. You need to use a launcher compatible with your MPI. In any case since to my understanding with the Makefiles provided by this project it works I am closing this.


Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000086:SSL routines::certificate verify failed

What happened?

Build Type
Standalone binary
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
PHP 8.3

Relevant log output
No response

This is a known issue: https://frankenphp.dev/docs/known-issues/#troubleshooting-tlsssl-issues-with-static-binaries. You need to configure your binary to point to the appropriate CA certificate bundle.


Provide a library for 64bit Ubuntu 22.04

Ubuntu 22.04 was released this April, can you provide DRFL library for this distro for those who want to use the latest and greatest software?

There are currently no plans for that matter.

@kirillmorozov
We will notify you again when the ubuntu 22.04 LTS library is available.

Just curious to see whether there have been any updates here @doosan-robotics?
Would you happen to have a version of API-DRFL that's compatible with 22.04?


Gradle setup needs cleanup

There are a lot of things to unclutter.

[x] Remove git submodules: There are submodules for dependency building that are not needed anymore. We take the dependencies from registries, and local testing can be done by command line substitution (e.g. ./gradlew --include-build ../path/to/repo build, requires compatible gradle versions, unfortunately).
[x] There are gradle file susing these submodules. They can be removed.
[x] Remove unnecessary dependencies
[x] Some dependencies can be updated
[x] Some gradle plugins can be updated.
[x] Documentation might need to adjusted accordingly.
[ ] Follow the template of the DEM Github group.

[ ] Update to new service-base version
[ ] Consider removing lombok dependency and instead generating code directly using the IDE.


fix: prune connections based on stream counts and direction

Changes how we sort connections to prune to be more than just tags and age.
Now we'll sort by tags, the number of open streams, direction and age.
This should choose idle connections without streams to close over those that are in use.
Change checklist

[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
[x] I have added tests that prove my fix is effective or that my feature works

would like to hear the rationale behind the changes.

If we do something like a DHT query, we open a connection to a peer, open a /ipfs/kad/1.0.0 stream, send a message and read the response.  We do this repeatedly and eventually hit the max connections limit.  The pruner tries to close some connections to bring us back under the limit while we're trying to continue the query.
The older connections are less useful now, since that peer plays no further part in the query.  The more useful connections are the ones we're trying to open to continue the query - these are the newest connections so right now would be the ones that get closed by the pruner, almost immediately after being opened.  Oops.
Instead, we should look for connections that have no open streams - these are safe(r) to close because no protocol is using them.

Thanks for the clarification


Update stepzen.config.json

This was asking the config name when it should be

The config was asking for an API name which was overwriting the config's name value. The API name wasn't even used in the schema.


[BUG] rpm repo redhat-et has old version v4.8.0

What happened?
I followed the install instructions here: https://microshift.io/docs/getting-started/ and ended up with rpm package 4.8.0-2022_04_20_141053.el9
What did you expect to happen?
There should be a more recent version of microshift available from rpm repo: https://copr.fedorainfracloud.org/coprs/g/redhat-et/microshift/

The team has not had capacity to resume COPR builds, but there are pre-release RPMs available from the releases page here on GitHub (https://github.com/openshift/microshift/releases). The docs on microshift.io are for the COPR builds. You will find product documentation for more recent versions on the RedHat portal (https://access.redhat.com/documentation/en-us/red_hat_build_of_microshift/4.14). A free developer account there should give you access to everything you need to see the docs and access the RHEL package repositories.


TypeError: Cannot read property 'allWordpressPost' of undefined

While issuing command "gatsby develop mysitename"
getting error: - TypeError: Cannot read property 'allWordpressPost' of undefined
though required plugin "wpspark lite" is installed in self-hosted WP deployment.
node -v
v10.16.0
gatsby -v
Gatsby CLI version: 2.7.47
Gatsby version: 2.15.14
Thanks

While issuing command "gatsby develop mysitename"
getting error: - TypeError: Cannot read property 'allWordpressPost' of undefined
though required plugin "wpspark lite" is installed in self-hosted WP deployment.
node -v
v10.16.0
gatsby -v
Gatsby CLI version: 2.7.47
Gatsby version: 2.15.14
Thanks

also prior to this getting error
"gatsby-node.js" threw an error while running the sourceNodes lifecycle:
connect ECONNREFUSED <IP_ADDRESS>:443

The error only get fixed when I remove
${process.env.protocol}://${process.env.baseUrl}
in gatsby-node.js and replaced it with actual url i.e. https://abc.com
same I did in gatsby-config.js for wordpress source plugin
baseUrl: "blog.abc.com",
protocol: "https",
so something wrong in getting the value from .env file from env folder
thanks


Always installs as root and in root directory

Default installs to root user and I tried with become_user & sudo then it installs to root user :(
I am using Vagarnt CentOS7
My Playbook
gather_facts: yes
become_user: vagrant
remote_user: vagrant
become: true
become_method: sudo
vars_files:
- vars/main.yml
roles:
- mdklatt.python3
My Vars
python3_pyenv: "3.5.6"
python3_command: python3.5
python3_bashrc: "/home/vagrant/.bash_profile"
python3_local: "/home/vagrant/.local/bin"

@raghuunravel
I'm not sure I understand the problem you're having. The default should not install to the root user (root?) if you're using a straightforward Vagrant install.
If you want Python 3 and utilities installed for user vagrant on the VM, the role defaults should work. I use this for deployments to AWS and VM clusters as well, and it works as expected (I've only tested the pyenv install option on Vagrant).
Here's what I get when I run the role on a fresh Vagrant CentOS VM (bento/centos-7.5). I'm using macOS Sierra (10.12.6) running Ansible v2.6.6 as the host system.
- hosts: all

  vars:
    - python3_pyenv: "3.5.6"
    - python3_command: python3.5

  roles:
    - name: mdklatt.python3

This is what I see after logging in to the new VM:

Everything is installed for user vagrant, as intended. Here is ~vagrant/.bash_profile:
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH
# BEGIN ANSIBLE MANAGED BLOCK
export PATH="/home/vagrant/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
# END ANSIBLE MANAGED BLOCK
export PATH=/home/vagrant/.local/bin:$PATH

One difference is that I'm just using the default values for the role variables, whereas you're explicitly defining them. The results should be the same, however.
If your intent is simply to make this work for user vagrant, you should not need these variables in your playbook:
become_user: vagrant
remote_user: vagrant
become: true
become_method: sudo

Other than using become: true, I'm not very familiar with privilege escalation in Ansible, so I'm not sure what the effect of these will be. Try using the simplified playbook I posted, and see if that helps.

No follow-up on this since last year, so considering this specific issue resolved. Multi-user installation does need to be improved for non-Vagrant installs, though, especially pyenv installs.


Created STIX 2.0 Getting Started guide and TAXII Intro pages

--Added Getting Started content including diagrams and code
--Added TAXII intro content including diagram
--Updated header dropdown
--Updated "last_updated" in config file
Last Updated Time Change
Before submitting the pull request, please update the last_updated on https://github.com/oasis-open/cti-documentation/blob/general_refinement/_config.yml#L16

@Bojak4616 can you look at this and merge if you don't see any issues?

@ATweedMITRE I changed a couple things to clean it up, most of it is great. Just FYI, it's best practice when having an external link to open it in a new tab. Can be done in markdown with
{: target="_blank"}.
Also, I changed https://github.com/oasis-open/cti-documentation/pull/30/commits/b28b3a27dcd475e25c82348ecb167e8e7e66f430#diff-121e250490617d8af528295e3138e8d3R13 to point to the FAQ instead of a dead link. I named it review previously, so I can understand the confusion.

Looks great, @ATweedMITRE . Thanks, @Bojak4616


remove 'xserver' prefix from libinput

hello, another very useful PR to remove a nix warning :)

hm, weird that the build is failing - my nixpkgs fe2ecaf706a5907b5e54d979fbde4924d84b65fc gives a deprecation warning for the xserver path

It's because head branch for this PR is still on an older nixpkgs revision. If you rebase it on main branch and force-push it should be fine


Fixed handling of confirm-def-push option

The flag was overriden with whatever was loaded from configuration file
it it existed. Now the flag takes precendence.
Signed-off-by: Michal Minar<EMAIL_ADDRESS>

Merged


Update the seed to set Distribution state from 'started' to 'scheduled'

Summary
We noticed that Distributions generated by the seed have this 'Started' state whereas it should be 'Scheduled'. Please update the seed so that we have them be 'Scheduled'.
You should be able to find the issue or the area needing to change inseeds.rb
Things to Consider
You can double check that it worked by seeding and logging in then going to the Distributions page. This state column should not include 'Started'

Criteria for Completion

[ ] Seeded Distribution do not have the status of 'started' but rather 'scheduled'

@c-bartell hey there I read your comment in the slack. And I thought it was a bit better to message in here.

Hey all! I'm working on issue #2311 and I noticed that the default value for state is 'started' in the schema and on the Distribution model. I'm still familiarizing myself with the app and I wanted to get some clarification. It this how distribution creation is intended to happen, and the seeds just need to be instantiated with a state value that is different from the default, or is the current issue a result of the default value being incorrect?

No worries and good question! So the issue I see is that the default value is incorrect, in that our code for distribution creation always sets it to scheduled. See that here
I like that you brought up the schema. My thoughts is you could do these two things which would be even better than updating the seed:

[ ] Change the default of the column from started to scheduled.
[ ] Remove the started state.
[ ] Remove the line of code in the link above since we no longer need to call scheduled! once the default has been changed.

Let me know if you have any questions


Form-item: fix "required" attribute is not effective for validation

Please make sure these boxes are checked before submitting your PR, thank you!

[x] Make sure you follow Element's contributing guide (中文 | English).
[x] Make sure you are merging your commits to dev branch.
[x] Add some descriptions and refer relative issues for you PR.

Could you write a demo to reproduce this bug?

Here is the link: https://codepen.io/anon/pen/yzXLRE?editors=1010
When 'isRequired' is changed, it can only change class of the 'form-item' component, but not its validate rules.
That is because in the 'mounted' hook, it can't not create a listen for event 'el.form.blur' or 'el.form.change' when 'getRules' returns an empty array no matter it has a 'required' attribute or not.
But even if you add 'rules' in the form-item component, the 'required' attribute still can not effect the validate rules. Because it doesn't look for the 'required' attribute while building rules for validation.

Thanks.


InMemory provider does not throw exception when trying to update or delete with an invalid primary key

InMemory provider does not throw exception when trying to update or delete with an invalid primary key. Attached is the test code that compares the behavior of Sqlite and InMemory providers when trying to update or delete with an invalid primary key.
InvalidIdTests.zip

Duplicate of https://github.com/aspnet/EntityFramework/issues/3953


Change extension rating system

Hi! I would like to suggest removing the 1-5 star rating system for extensions.
Why?
Real users of extensions rarely leave reviews. At a minimum, you need to register to do this, which often stops you. But unscrupulous developers may deliberately lower the ratings of other extensions in order to lower position in search results and raise own extensions. In my case, one 1-star review dropped my extension in search from 5 to 11 position. Also, such a review may simply not be objective and unfair. This can be frustrating and demotivating for developers who don't get a penny for their efforts (vast majority). Even if there really is some kind of bug in the extension, I consider it good practice to create an issue on Github.
What to do?
Instead of the five-rank rating, make one button "👍 36 liked". Or as on GitHub: "⭐ 36 stars". Instead of reviews (comments), I would add a "Issues" section.

Thank you for reaching out to the VS Marketplace Team and for taking the time to provide feedback. We will promptly review the feedback.
Regards,
VS Marketplace Team

Closing this issue as we are tracking in https://github.com/microsoft/vsmarketplace/issues/150


Update note tx.locktime

update note to reflect tx.locktime only has an advantage over tx.time when using the nlocktime in the simulated state

Thanks!


Update D:\Git\winget-pkgs\manifests\m\MongoDB\Server\6.0.6

Microsoft Reviewers: Open in CodeFlow

No time, but still working on it

@wingetbot run

This PR omits these files that are present in the current manifest:

@{InputObject=yaml; SideIndicator=<=}

(Automated response - build 498.)


[BUG] Transition hangs after 400~500 page visit

Hello! It's me again.
I updated to the latest version and really decided to try out the view transition API. It works very well and looks very smooth.
However, I encountered a weird behaviour. After visiting a 400~500 status code page (like a 404 page), future navigation will hang for a long time (a few seconds) during which I cannot do anything on the page. It's definitely not a speed problem, as the networks tab completes instantly. Removing Turn also gets rid of the problem. I created a new quick Symfony app and tried it without any other package and with default transitions, and the problem persists. I also tried to set Turn.config.experimental.viewTransitions = false; but it doesn't seem to do anything? It's still using the view transition API, I believe (dunno if this is intended).
Looking in the DevTools, it seems that the transition API tries to animate something? Because I can see the ::view-transition appear while it hangs. It's also worth noting that it does not happen when I visit the 404 page directly from my browser and then click on the homepage. It only happens when Turbo visits the 404 link.
If needed, I can create a quick repository to highlight what I did exactly and what the problem is (I only tested it in Symfony apps, but I doubt it's a problem with it, I just built the assets normally using Webpack).

Here's a quick video I made to showcase the problem. You can see that right after I visit the 404 page, all visits hang for a few seconds.
https://github.com/domchristie/turn/assets/61044908/e332fca3-44a7-45e4-bb89-1afd7f9c0f42

Thanks for this. I'll look into it.

It looks like turbo:load is not fired when the response errors. I'll see if there's a workaround, but I've raised an issue here: https://github.com/hotwired/turbo/issues/958

Thanks for such a quick response (and PR to fix the problem) ! In the meantime, is there any (even dirty) workaround to it? I was thinking about just disabling Turn during error pages, but I'm not too sure on what's the best way to do it.

Unfortunately there currently isn't a workaround. You may wish to use Turn v2.1, as this does not have View Transitions enabled by default.
Aside: In my own 404 tests, I'm not seeing any hanging. However I have noticed that the turn-enter and turn-advance classes are not being removed, so there's definitely something wrong.

Well, I ended up just deactivating drive navigation on those pages using the meta tag, causing a full page reload after navigating out. The only case where it will not work is when you hit the back button and Turbo performs a restoration. I suppose it could even be better to completely disable Turbo temporarily on those pages.
But I see that https://github.com/hotwired/turbo/pull/960 has been merged, so I'm hoping for a release sooner or later :slightly_smiling_face:


Updated app label and icons to S1 branding

Jira Link: https://sentinelone.atlassian.net/browse/{TICKET}
🥅 Goal
Explain why is this change needed
🛠 Solution
Provide description of changes
🏫 Testing
How the changes were tested

Looks good

Based on my observations there is light and dark theme. Have you tested this with both themes? There is some ongoing discussion about the colour scheme.

The new images were pulled from the existing SentinelOne App for Splunk.


Added Dropdown Category and some components

Fixes Issue🛠

Closes #527
Description👨💻
Added Dropdown Component and some Dropdowns
Type of change📄

[] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

How this has been tested✅

Checklist✅

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added demonstration in the form of GIF/video file
[x] I am an Open Source Contributor

Screenshots/GIF📷

Please include a message text on the More Menu Dropdown webpage indicating that users can click on the dots to reveal the dropdown @AbhineshJha

Fixed @Rakesh9100 !!!

Merged 🥳 @AbhineshJha


Seconds are counted from 0 to 60

In currenttime display seconds are counted from 0 to 60, should be up to 59.

can you provide a URL to see this issue please?

http://www.mediaelementjs.com/ ;)
You can see this in the player with bunny movie.

Got it. I'll take a look and fix it soon. Thanks. Please star the project to support it

@gmichlicki-neducatio This should be fixed now; please download the master branch and confirm, please. Thanks

It works now! Thank you

You are welcome 👍


create a demo notebook to illustrate solving the 3D diffusion equation in a cylinder

[x] 3D diffusion equation with full BCs
[x] 3D graphics
[ ] have simulation function accept sim parameters
[ ] check scaling
[ ] supply notebook documentation
[ ] add cross-section plots

[x] 1D
[ ] 2D

[ ] update from mshr to alternate mesh generator moved to #36

@dtabell -- can this be closed?

@dtabell -- please provide a link to the notebook and update the status of this issue.

Lowering priority. @dtabell -- please post a link to the notebook in question.

Multiple notebooks illustrate this. The latest, which includes the the nonlinear heat equation appears in
https://github.com/radiasoft/rslaser/blob/master/examples/thermal/NLThermalSaturation.ipynb


np.round question

I didnot use np.round on A2 when I do the assignment by myself, so I got a predictions mean = 0.500891384745, which is not as the same as the expected result. But the code was still working and I got a result which have only the accuracy = 85%. The boundary picture is also different from the expected result, it has 4 colors.

Then I found your code on github, you used a np.round on A2, and got the results.
Could you explain why we should use a round function here, and why only a simple round function can enhance the results so much. Thank you and thank you for your code.

Hi, I'm not sure whether you are talking about section 4.5 prediction. Let's just assume I am correct.
You can see the formula in the remainder part.

np.round is a equivalent function of np.around, which help you with the rounding part.
Just 四舍五入 it.


issue-272: Shouldn't _rec- be excluded from "functional run/task identity"?

After adding rec- to the list where it shouldn't check for task name, there are other warnings as generated below:
`2: You should define 'EchoTime' for this file. If you don't provide this information field map correction will not be possible. (code: 6 - ECHO_TIME_NOT_DEFINED)
/sub-Exp1s03/func/sub-Exp1s03_task-routelearning_rec-retest_run-02_bold.nii.gz
3: You should define 'PhaseEncodingDirection' for this file. If you don't provide this information field map correction will not be possible. (code: 7 - PHASE_ENCODING_DIRECTION_NOT_DEFINED)
	/sub-Exp1s03/func/sub-Exp1s03_task-routelearning_rec-retest_run-02_bold.nii.gz

4: You should define 'EffectiveEchoSpacing' for this file. If you don't provide this information field map correction will not be possible. (code: 8 - EFFECTIVE_ECHO_SPACING_NOT_DEFINED)
	/sub-Exp1s03/func/sub-Exp1s03_task-routelearning_rec-retest_run-02_bold.nii.gz

5: You should define 'SliceTiming' for this file. If you don't provide this information slice time correction will not be possible. (code: 13 - SLICE_TIMING_NOT_DEFINED)
	/sub-Exp1s03/func/sub-Exp1s03_task-routelearning_rec-retest_run-02_bold.nii.gz

6: Task scans should have a corresponding events.tsv file. If this is a resting state scan you can ignore this warning or rename the task to include the word "rest". (code: 25 - EVENTS_TSV_MISSING)
	/sub-Exp1s03/func/sub-Exp1s03_task-routelearning_rec-retest_run-02_bold.nii.gz`

I have added filter to exclude files with 'rec-' for above checks.

Closes #272.

Try modyfying https://github.com/INCF/bids-validator/blob/master/validators/nii.js#L271
Similar code has been implemented in grabbits https://github.com/grabbles/grabbit/blob/46d60a056fabf2eb1e68b56371a81213caaaaad9/grabbit/core.py#L333

for reconstructed task runs with k:v pair _rec-, all required metadata fields will be acquired from corresponding non reconstructed task .json. Similarly it will take care of events.tsv file too.
@chrisfilo - Can you please review the PR?
I am not quite sure what has to be done with appveyor error above.

Step one: improve description of inheritance rule in the spec - https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit#heading=h.tfkd82hi8cl8
Step two: implement a generic traversal of directories and key/value pairs that goes beyond the "rec" key (see how it's implemented in grabbids).

Is this ready to review?

Not yet. I am yet to implement hierarchy rule.
Now that it's hierarchy rule is added to BIDS spec I will implement it in validator.


#4772 Smaller App Updates

Balance of Satoshis 19.3.4
Lablebase 2.2.2
Thunderhub v0.13.31

All updates worked on my test machine.


Remix is not supported

I'm using Spline in Remix, but I get this error:

import Spline from "@splinetool/react-spline"
<div>
    <Spline scene="https://prod.spline.design/zPJieC7eD-JWZ-7X/scene.splinecode"/>
 </div>

package.json
{
  "private": true,
  "sideEffects": false,
  "type": "module",
  "scripts": {
    "build": "remix build",
    "deploy": "wrangler deploy",
    "dev": "remix dev --manual -c \"npm start\"",
    "start": "wrangler dev ./build/index.js",
    "typecheck": "tsc"
  },
  "dependencies": {
    "@cloudflare/kv-asset-handler": "^0.1.3",
    "@remix-run/cloudflare": "*",
    "@remix-run/css-bundle": "*",
    "@remix-run/react": "*",
    "@splinetool/react-spline": "^2.2.6",
    "@splinetool/runtime": "^0.9.510",
    "isbot": "^3.6.8",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@cloudflare/workers-types": "^4.20230518.0",
    "@remix-run/dev": "*",
    "@remix-run/eslint-config": "*",
    "@types/react": "^18.2.20",
    "@types/react-dom": "^18.2.7",
    "eslint": "^8.38.0",
    "typescript": "^5.1.6",
    "wrangler": "3.8.0"
  },
  "engines": {
    "node": ">=18.0.0"
  }
}

Any help would be appreciated!

Also very interested on how to make this work with remix2
Any solutions?

This is working for us in Remix, though we do have to lazy load the dependency client side.
import {lazy} from 'react';

// Spline must be lazy loaded or it throws and error on the Guest UI
const Spline = lazy(() => import('@splinetool/react-spline'));

Hi since version 3.1.0 of splinetool/react-spline remix works by default without the need for lazy.


fix(ui): replace new edit icon and glossary feedback

Describe your changes:
Permission related issues in Glossary
Updating edit icon across OM

I worked on ... because ...

Type of change:

[x] Bug fix
[x] Improvement

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] My PR title is Fixes <issue-number>: <short explanation>
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

@karanh37 @chirag-madlani can we merge this in?

@karanh37 @chirag-madlani can we merge this in?

@harshach has some cy failures, updated with main will merge once cy is green