Multi Platform support for Pipfile.lock

Is your feature request related to a problem? Please describe.
Currently it is not possible to create a Pipfile.lock for multiple platforms automatically.
Only hashes for the current platform are locked.
This is problematic when you want to use Pipefile.lock to share locked dependency versions in a multi platform setup, e.g. development on Windows or Mac and production on Linux.
E.g. cryptography generates the following Pipfile.lock entry on Windows 10 64bit:
        "cryptography": {
            "hashes": [
                "sha256:471e0d70201c069f74c837983189949aa0d24bb2d751b57e26e3761f2f782b8d",
                "sha256:f224ad253cc9cea7568f49077007d2263efa57396a2f2f78114066fd54b5c68e"
            ],
            "markers": "python_version >= '3.6'",
            "version": "==37.0.2"
        },

and the following one on a Linux VM:
        "cryptography": {
            "hashes": [
                "sha256:0cc20f655157d4cfc7bada909dc5cc228211b075ba8407c46467f63597c78178",
                "sha256:2bd1096476aaac820426239ab534b636c77d71af66c547b9ddcd76eb9c79e004",
                "sha256:59b281eab51e1b6b6afa525af2bd93c16d49358404f814fe2c2410058623928c",
                "sha256:f224ad253cc9cea7568f49077007d2263efa57396a2f2f78114066fd54b5c68e"
            ],
            "markers": "python_version >= '3.6'",
            "version": "==37.0.2"
        },

Describe the solution you'd like
My preferred solution would be a new entry in the Pipfile that defines which platforms hashes must always be included when locking.
If the current systems platform isn't in the list it should be be added to the lock list though to retain backwards compatibility.
The Pipfile entry could look like this:
[[source]]
platforms = "manylinux_2_24_x86_64 or win_amd_64"

If possible it would be great if the values could be eagerly validated and an error message printed on invalid values.
Note: Ticket https://github.com/pypa/pipenv/issues/210 is similar to this one, but I was asked to open a new ticket

Could the lock file just be per-platform/version/etc?
Pipfile defines my sources and packages.

When I pipenv lock on my Python 3.8 on Windows 64bit, why couldn't it produce a Pipfile.3.8.windows.x64.lock.
If I try to pipenv sync on Python 3.10, since there is not Pipfile.3.10.windows.x64.lock, the normal behavior would kick in and a new lock would be generated.
Likewise, if I pipenv lock on Linux python 3.10, then it would generate a Pipfile.3.10.linux.x64.lock.

What would be the drawback to that type of approach, aside from legacy support for the existing Pipfile.lock?

What would the advantage of maintaining multiple lock files per platform and environment @dijital20 ?  I am not a big fan of the idea of having platform specific lock files and then how to know which one to use during sync.

could the normal behavior kick in and a new lock would be generated?

Not for sync -- that would be very very bad because you loose the trust that you are verifying the dependencies you used in dev/test are the same you are deploying to production because the hashes would regenerate.
The current design can be extended to account for multiple platforms already -- for multi-platform dependencies all of the associated hashes are included in the lock, so this issue is really about dependencies that are for a different platform than the one you are locking on should also be included in this lock file with the relevant platform marker.  Today this only happens if you lock on the environment that requirement is compatible with.  Pipenv's own lock file has this problem -- if we do not lock on windows we loose a windows-specific dependency from the lock file.

Yeah, platform-specific and Python-version-specific dependencies are the issue to solve here.
I had similar issues though when I moved a project from Python 3.8 to Python 3.10. My Pipfile and lock files both had Python 3.8 in them, and the standard pipenv sync --dev failed unless I did pipenv sync --dev --python C:\python310\python.exe, and then re-locked. At that point, everyone using Python 3.8 was out of luck, and so was anyone on Python 3.10.

I am not a big fan of the idea of having platform specific lock files and then how to know which one to use during sync.

pipenv when called, would generate the lock file name based on the interpreter. In my examples, the names were pipfile.{version}.{platform}.{architecture}.lock. If the file exists, party on. If the file doesn't exist, then it should behave the same way pipenv does today if the lock file doesn't exist.
I am not sure if platform-specific lock files is the solution... just thinking through it as we ran into this today, as a colleague is developing a new Python module that he wants to support both Windows and Linux on, but there are some dependencies which are platform specific.

@dijital20 or @xyxz-web -- were either of you by chance using private python repositories isntead of pypi?  I just locked on the latest pipenv main on windows and cryptography has a lot more hashes -- like all of them -- than the original example had.
        "cryptography": {
            "hashes": [
                "sha256:093cb351031656d3ee2f4fa1be579a8c69c754cf874206be1d4cf3b542042804",
                "sha256:0cc20f655157d4cfc7bada909dc5cc228211b075ba8407c46467f63597c78178",
                "sha256:1b9362d34363f2c71b7853f6251219298124aa4cc2075ae2932e64c91a3e2717",
                "sha256:1f3bfbd611db5cb58ca82f3deb35e83af34bb8cf06043fa61500157d50a70982",
                "sha256:2bd1096476aaac820426239ab534b636c77d71af66c547b9ddcd76eb9c79e004",
                "sha256:31fe38d14d2e5f787e0aecef831457da6cec68e0bb09a35835b0b44ae8b988fe",
                "sha256:3b8398b3d0efc420e777c40c16764d6870bcef2eb383df9c6dbb9ffe12c64452",
                "sha256:3c81599befb4d4f3d7648ed3217e00d21a9341a9a688ecdd615ff72ffbed7336",
                "sha256:419c57d7b63f5ec38b1199a9521d77d7d1754eb97827bbb773162073ccd8c8d4",
                "sha256:46f4c544f6557a2fefa7ac8ac7d1b17bf9b647bd20b16decc8fbcab7117fbc15",
                "sha256:471e0d70201c069f74c837983189949aa0d24bb2d751b57e26e3761f2f782b8d",
                "sha256:59b281eab51e1b6b6afa525af2bd93c16d49358404f814fe2c2410058623928c",
                "sha256:731c8abd27693323b348518ed0e0705713a36d79fdbd969ad968fbef0979a7e0",
                "sha256:95e590dd70642eb2079d280420a888190aa040ad20f19ec8c6e097e38aa29e06",
                "sha256:a68254dd88021f24a68b613d8c51d5c5e74d735878b9e32cc0adf19d1f10aaf9",
                "sha256:a7d5137e556cc0ea418dca6186deabe9129cee318618eb1ffecbd35bee55ddc1",
                "sha256:aeaba7b5e756ea52c8861c133c596afe93dd716cbcacae23b80bc238202dc023",
                "sha256:dc26bb134452081859aa21d4990474ddb7e863aa39e60d1592800a8865a702de",
                "sha256:e53258e69874a306fcecb88b7534d61820db8a98655662a3dd2ec7f1afd9132f",
                "sha256:ef15c2df7656763b4ff20a9bc4381d8352e6640cfeb95c2972c38ef508e75181",
                "sha256:f224ad253cc9cea7568f49077007d2263efa57396a2f2f78114066fd54b5c68e",
                "sha256:f8ec91983e638a9bcd75b39f1396e5c0dc2330cbd9ce4accefe68717e6779e0a"
            ],
            "index": "pypi",
            "version": "==37.0.2"
        },

For cryptography, there's a compiled component written in Rust which is packaged along with the Python code. This would be different per-platform, which accounts for the different hashes per platform. This page on PyPI shows the different platform variations of the files:
https://pypi.org/project/cryptography/#files
The lock you posted @matteius looks like it got all of them. What @xyxz-web is seeing are probably the ones appropriate for the platform and interpreter they're using.
Like I said, I have a colleague who is trying to author a new package and wants to support both Windows and Linux, so he's developing out of both Windows and WSL2 Ubuntu. At least one of the dependencies (I suspect lxml) is different between the platforms, so if he locks on one platform, the lock file doesn't work on the other and vice versa.
We have changed to using lock on Windows, and then lock --keep-outdated on the Linux, but there's got to be an easier, slightly more obvious way.
I hope this is helpful. :) Thank you for the discussion on this.

@dijital20 You are right that locked that on windows, but I just tried on Ubuntu and got the same result:
        "cryptography": {
            "hashes": [
                "sha256:093cb351031656d3ee2f4fa1be579a8c69c754cf874206be1d4cf3b542042804",
                "sha256:0cc20f655157d4cfc7bada909dc5cc228211b075ba8407c46467f63597c78178",
                "sha256:1b9362d34363f2c71b7853f6251219298124aa4cc2075ae2932e64c91a3e2717",
                "sha256:1f3bfbd611db5cb58ca82f3deb35e83af34bb8cf06043fa61500157d50a70982",
                "sha256:2bd1096476aaac820426239ab534b636c77d71af66c547b9ddcd76eb9c79e004",
                "sha256:31fe38d14d2e5f787e0aecef831457da6cec68e0bb09a35835b0b44ae8b988fe",
                "sha256:3b8398b3d0efc420e777c40c16764d6870bcef2eb383df9c6dbb9ffe12c64452",
                "sha256:3c81599befb4d4f3d7648ed3217e00d21a9341a9a688ecdd615ff72ffbed7336",
                "sha256:419c57d7b63f5ec38b1199a9521d77d7d1754eb97827bbb773162073ccd8c8d4",
                "sha256:46f4c544f6557a2fefa7ac8ac7d1b17bf9b647bd20b16decc8fbcab7117fbc15",
                "sha256:471e0d70201c069f74c837983189949aa0d24bb2d751b57e26e3761f2f782b8d",
                "sha256:59b281eab51e1b6b6afa525af2bd93c16d49358404f814fe2c2410058623928c",
                "sha256:731c8abd27693323b348518ed0e0705713a36d79fdbd969ad968fbef0979a7e0",
                "sha256:95e590dd70642eb2079d280420a888190aa040ad20f19ec8c6e097e38aa29e06",
                "sha256:a68254dd88021f24a68b613d8c51d5c5e74d735878b9e32cc0adf19d1f10aaf9",
                "sha256:a7d5137e556cc0ea418dca6186deabe9129cee318618eb1ffecbd35bee55ddc1",
                "sha256:aeaba7b5e756ea52c8861c133c596afe93dd716cbcacae23b80bc238202dc023",
                "sha256:dc26bb134452081859aa21d4990474ddb7e863aa39e60d1592800a8865a702de",
                "sha256:e53258e69874a306fcecb88b7534d61820db8a98655662a3dd2ec7f1afd9132f",
                "sha256:ef15c2df7656763b4ff20a9bc4381d8352e6640cfeb95c2972c38ef508e75181",
                "sha256:f224ad253cc9cea7568f49077007d2263efa57396a2f2f78114066fd54b5c68e",
                "sha256:f8ec91983e638a9bcd75b39f1396e5c0dc2330cbd9ce4accefe68717e6779e0a"
            ],
            "index": "pypi",
            "version": "==37.0.2"
        },

I am going to need y'all to provide the output from pipenv --support to further debug,

I also get the long list of hashes when I lock from within WSL - seems to include both Windows and Linux hashes.
However, when I lock from within Windows 10 or a Linux VM, I get a much shorter list.
I'm usinge a private repo here, but it is automatically mirrored from pypi.

@xyxz-web hash collection of all packages is a specific feature of pypi.   There is no API into private pypi servers for collecting the set of hashes, and I suspect that is where the problem comes in.  For reference, here is the code that collects the hashes:  https://github.com/pypa/pipenv/blob/main/pipenv/utils/resolver.py#L757-L788  Specifically look for where it collects hashes from pypi:  https://github.com/pypa/pipenv/blob/main/pipenv/utils/resolver.py#L726-L755
I would recommend if possible to use pypi as a primary index in the Pipfile and support your private packages as a secondary index calling out specifically the private index to pull those specific packages from.

how to know which one to use during sync

@matteius  perhaps with:
import platform

# somwehere inside the `sync` method definition
open(f"Pipfile.lock.{platform.machine()}")

I think this is a really important problem to solve right now. For example, if we have a project that uses numpy as a dependency and we have an x86_64 server, Github Actions CI also on x86_64, 1 developers on Linux x86_64, one on older x86_64 Mac and  one more with an M1 Macbook arm64. Each time someone updates the lockfile, at least one person has problem. At the moment, one quick solution I found was to manually modify the Pipfile.lock file and add this (for numpy):
"markers": "(platform_machine == 'x86_64' or platform_machine == 'arm64') and python_version < '3.10'",

(the above allows me to work on M1 Mac and run CI on x86_64 Github Action + deploy to amd64 Linux server)
The Ruby Bundler solves this problem by adding separate lock file entries for each platform, e.g.
nokogiri (1.13.6)
nokogiri (1.13.6-aarch64-linux)
nokogiri (1.13.6-x86_64-darwin)
nokogiri (1.13.6-x86_64-linux)

I think this is a really important problem to solve right now.

I agree with you, it is becoming higher on the list of priorities and we have tackled a number of other bugs and technical debt items that set us up better to work on this.   I am inclined to try and find a solution that will work with the single Pipfile.lock than rather try to support multiple lock files by platform.  I am not quite sure how it would work though for something that has to be built on that system architecture in order to generate the appropriate hashes because how could it build all of the architectures at once?  That is probably where the thinking to have a separate platform specific lockfiles comes into play but I need to give this problem more time and consideration as well as additional inputs will be helpful.
@januszm Can you explain more about your workaround "markers": "(platform_machine == 'x86_64' or platform_machine == 'arm64') and python_version < '3.10'", -- can you provide more context, maybe the whole block from that part of the lockfile so I can get a better idea of what the workaround is doing.
Another thing I have been thinking more about as it relates to pre-built wheels and private pypi's, is it would be great if we could get the private pypi servers to support a similar json API to pypi for fetching the available package hashes.  Of the data that API returns, pipenv specifically leverages the part of the payload that is:
api_releases = r.json()["releases"]
to have the versions as keys with each having a key ["digests"]["sha256"] which would be the package hash for that version package.  If we knew that more private pypi servers supported this informational package API, then we could update our logic here to try this for more than just pypi.org: https://github.com/pypa/pipenv/blob/main/pipenv/utils/resolver.py#L727-L755
That wouldn't help for packages that need to be built on system architectures to get those hashes (because no pre-built wheels exist) but it would help in general with this issue and with performance, though a platform specific build solution I believe needs to exist as well to manage hashes generated from different lock architectures.  I think the numpy issue though, there are pre-built wheels for most architectures and pipenv will not pull all of the hashes from a private pypi because it would have to download all of the wheels because such an API is not supported.   Perhaps part of the solution could be an option to override and tell it to download all platform eligible wheels from a private pypi in order to collect all the hashes, but again I would need to study that code some more to find out.

Thanks for the detailed response @matteius . I don't know if I will be able to professionally explain what exactly this workaround is because I have never studied pip and pipenv internals, I am rather just a user of these systems. As I understand it, this line, adding or platform_machine == 'arm64' just lets pip build a local extension for numpy, it unlocks the installation process on arm64 platform.
I am not sure how hashes work in pip and pipenv but IMO it seems unnecessary to calculate hashes for extensions that are built locally. The hashes for the source code, which is common to all architectures, should provide necessary minimum security so it can be computed once. Probably that's why it works with my workaround, the hash of files that are built locally doesn't matter because they come from source code that already has hashes.

@januszm Thanks I will take a closer look at that later, fwiw, I think you may be actually installing pre-built wheels for the platform.   For example, there are prebuilt arm64 wheels for macos:  https://pypi.org/project/numpy/1.23.2/#files
The issue for pipenv though for pre-built wheels is when going through a private pypi, I believe it does not download all of the wheels to get the hashes, only the ones that match the system you are locking on.

I think you may be actually installing pre-built wheels for the platform

Ah true, if we could make pipenv work with all platforms, not only the one we're locking on, it would already be a great improvement

TL;DR another case where this issue has a negative impact is when trying to publish a Jupyter notebook using mybinder.
Details: I have a notebook that I develop locally (M1 mac) and I'm trying to serve it using https://mybinder.org/. During the build it seems like numpy was not installed due to the platform specified in the lock file. In turn, the served notebook fails... See this discussion for more details.
Possible workaround: In https://github.com/drorata/candy-analysis/commit/ed2c6eb46f1fb740a0efee3d208ebe92dcc5aeef I removed the Pipfile.lock so when the image will be built on mybinder's side, it will be free to pick the appropriate platform. This unblocked my build and running of the notebook inside mybinder.

One addition, FWIW: I now faced a similar related issue. I'm trying to dockerize some work which was developed on an M1 mac. To that end, in the Dockerfile I added:
COPY ./Pipfile* .

RUN python -m pip install --upgrade pip
RUN pip install pipenv && pipenv install --dev --system --deploy

It comes as no surprise, that I get the following warning: Ignoring appnope: markers 'platform_system == "Darwin"' don't match your environment. I tried not to copy the Pipfile.lock, but then it is not possible to use the --system flag when installing the environment. I don't think it harmed the running of the container but I find it very confusing.

@drorata I am not sure how the markers are making it into your Pipfile for numpy ... I just locked on many different systems numpy, on windows, linux VM, Mac M1, and all did not have the markers restricting numpy.   What version of pipenv are you on?

Also noting to the larger group that I am unable to reproduce getting not the full set of hashes for some of these packages on pipenv==2022.8.24 -- I tried multiple systems and I also tried pypiserver which mirrors pypi packages, and in all cases the lock file has the full set of hashes.   It appears even when it has to download the wheels, it downloads all of the matching version to get the hashes.   If anyone can provide more reproduction steps with the current version of pipenv I would like to look more into it.

@matteius Thanks for your answer! I'm used version 2022.8.17 (installed using brew). I upgraded it (to 2022.8.24) and now there are no markers in the Pipfile.lock. In turn the warning doesn't show up.

Does it mean this issue was fixed in 24.08?

Does it mean this issue was fixed in 24.08?

That's a bold statement @januszm. I'm not sure what's meant by "this issue". In my case, using the newer version yielded a Pipfile.lock file which didn't contain the "markers" and I was able to build the docker image without warnings.

I think it really needs to be one lockfile per platform because of stuff like: https://github.com/pandas-dev/pandas/blob/v1.4.3/setup.cfg#L33, which each platform has a different version requirement.  Otherwise locks would have to munge a single lockfile which could prove problematic due to competing requirements

I think it's worth looking at the poetry file format for this type of scenario:
[package.dependencies]
numpy = [
    {version = ">=1.18.5", markers = "platform_machine != \"aarch64\" and platform_machine != \"arm64\" and python_version < \"3.10\""},
    {version = ">=1.19.2", markers = "platform_machine == \"aarch64\" and python_version < \"3.10\""},
    {version = ">=1.20.0", markers = "platform_machine == \"arm64\" and python_version < \"3.10\""},
]

along with
numpy = [
    {file = "numpy-1.23.1-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:aeba539285dcf0a1ba755945865ec61240ede5432df41d6e29fab305f4384db2"},
    {file = "numpy-1.23.1-cp38-cp38-macosx_11_0_arm64.whl", hash = "sha256:7e8229f3687cdadba2c4faef39204feb51ef7c1a9b669247d49a24f3e2e1617c"},
    {file = "numpy-1.23.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:1408c3527a74a0209c781ac82bde2182b0f0bf54dea6e6a363fe0cc4488a7ce7"},
    {file = "numpy-1.23.1.tar.gz", hash = "sha256:d748ef349bfef2e1194b59da37ed5a29c19ea8d7e6342019921ba2ba4fd8b624"},
]

that way multiple versions are supported, with each platform getting what it requires

@thehesiod That is really complicated, I mean perhaps possible to specify all that to the pip resolver, but never the less couldn't your example be boiled down to this for pipenv locking and work properly?
numpy = {version = ">=1.20.0", markers = "python_version < '3.10'"}
Since if you specify all three constraints for version to the resolver, you are going to have to get one version that is compatible across all constraints, so you may as well go with version = ">=1.20.0" and then I guess the question becomes what are you trying to accomplish with all those marker constarints?   It is not clear from the example, but the above line resolves a lock file entry like:
        "numpy": {
            "hashes": [
                "sha256:17e5226674f6ea79e14e3b91bfbc153fdf3ac13f5cc54ee7bc8fdbe820a32da0",
                "sha256:2bd879d3ca4b6f39b7770829f73278b7c5e248c91d538aab1e506c628353e47f",
                "sha256:4f41f5bf20d9a521f8cab3a34557cd77b6f205ab2116651f12959714494268b0",
                "sha256:5593f67e66dea4e237f5af998d31a43e447786b2154ba1ad833676c788f37cde",
                "sha256:5e28cd64624dc2354a349152599e55308eb6ca95a13ce6a7d5679ebff2962913",
                "sha256:633679a472934b1c20a12ed0c9a6c9eb167fbb4cb89031939bfd03dd9dbc62b8",
                "sha256:806970e69106556d1dd200e26647e9bee5e2b3f1814f9da104a943e8d548ca38",
                "sha256:806cc25d5c43e240db709875e947076b2826f47c2c340a5a2f36da5bb10c58d6",
                "sha256:8247f01c4721479e482cc2f9f7d973f3f47810cbc8c65e38fd1bbd3141cc9842",
                "sha256:8ebf7e194b89bc66b78475bd3624d92980fca4e5bb86dda08d677d786fefc414",
                "sha256:8ecb818231afe5f0f568c81f12ce50f2b828ff2b27487520d85eb44c71313b9e",
                "sha256:8f9d84a24889ebb4c641a9b99e54adb8cab50972f0166a3abc14c3b93163f074",
                "sha256:909c56c4d4341ec8315291a105169d8aae732cfb4c250fbc375a1efb7a844f8f",
                "sha256:9b83d48e464f393d46e8dd8171687394d39bc5abfe2978896b77dc2604e8635d",
                "sha256:ac987b35df8c2a2eab495ee206658117e9ce867acf3ccb376a19e83070e69418",
                "sha256:b78d00e48261fbbd04aa0d7427cf78d18401ee0abd89c7559bbf422e5b1c7d01",
                "sha256:b8b97a8a87cadcd3f94659b4ef6ec056261fa1e1c3317f4193ac231d4df70215",
                "sha256:bd5b7ccae24e3d8501ee5563e82febc1771e73bd268eef82a1e8d2b4d556ae66",
                "sha256:bdc02c0235b261925102b1bd586579b7158e9d0d07ecb61148a1799214a4afd5",
                "sha256:be6b350dfbc7f708d9d853663772a9310783ea58f6035eec649fb9c4371b5389",
                "sha256:c403c81bb8ffb1c993d0165a11493fd4bf1353d258f6997b3ee288b0a48fce77",
                "sha256:cf8c6aed12a935abf2e290860af8e77b26a042eb7f2582ff83dc7ed5f963340c",
                "sha256:d98addfd3c8728ee8b2c49126f3c44c703e2b005d4a95998e2167af176a9e722",
                "sha256:dc76bca1ca98f4b122114435f83f1fcf3c0fe48e4e6f660e07996abf2f53903c",
                "sha256:dec198619b7dbd6db58603cd256e092bcadef22a796f778bf87f8592b468441d",
                "sha256:df28dda02c9328e122661f399f7655cdcbcf22ea42daa3650a26bce08a187450",
                "sha256:e603ca1fb47b913942f3e660a15e55a9ebca906857edfea476ae5f0fe9b457d5",
                "sha256:ecfdd68d334a6b97472ed032b5b37a30d8217c097acfff15e8452c710e775524"
            ],
            "markers": "python_version < '3.10'",
            "version": "==1.23.2"
        },

This includes all of the relevant hashes for this version.   Is there a platform you are trying to exclude numpy from?

I spent some time on this today and what I found was somewhat discouraging -- internal to the pip resolver the markers of transitive dependencies are processed and those requirements are discarded if they are not for your platform.   Pipenv has such a thing in its lock file: it depends on click which has metadata:
Requires-Dist: colorama ; platform_system == "Windows"
Requires-Dist: importlib-metadata ; python_version < "3.8"

So if we do not lock on Windows, the colorama is dropped from the lock file.    The problem with my code modifications had nothing to do with colorama, but other dependencies that did not have wheell/metadata for my system and so it tries to build that metadata but fails to do so because the marker was ignored that indicates it was not for my system.  I tried to hack around it, but I ended up in long locking phases that never ended, or ones that ended because some dependencie's possible extra could not generate the metadata on my system.
The interesting thing though, is by adding a * resolution of that same package to the Pipfile, then the lock does work on linux and does not drop the colorama.  For example adding: colorama = {version = "*", markers="sys_platform == 'win32'"} to the Pipfile of pipenv and locking on linux does not change the coloarama in the lock file.    I note this as a workaround to a fairly complex problem that I don't see an easy solution for.   It is interesting though, requirementslib has a setup.py reader that generates some kind of metadata without invoking any of the setup.py logic, which seems quite different from what the pip resolver is doing--the pip resolver I believe is designed to prep packages for install and so perhaps it is reusing logic for getting the metadata that assumes the package will definitely be installed on that system, when what we want is to be able to resolve a proper lockfile that includes all platforms with the relevant markers.

I am thinking that named categories may help out with this issue -- See: https://github.com/pypa/pipenv/pull/5366
For example:
$ cat Pipfile
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
requests = "*"

[dev-packages]

[requires]
python_version = "3.10"

[linux]
numpy = "*"

[windows]
numpy = "==1.22.4"

matte@LAPTOP-N5VSGIBD MINGW64 ~/Projects/pipenv-triage/multi-platform
$ cat Pipfile.lock
{
    "_meta": {
        "hash": {
            "sha256": "18815ba6d0514cb0588df0a7bc63bca22ea99223fc0ba15281b0258dbefff304"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.10"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {},
    "develop": {},
    "linux": {
        "numpy": {
            "hashes": [
                "sha256:004f0efcb2fe1c0bd6ae1fcfc69cc8b6bf2407e0f18be308612007a0762b4089",
                "sha256:09f6b7bdffe57fc61d869a22f506049825d707b288039d30f26a0d0d8ea05164",
                "sha256:0ea3f98a0ffce3f8f57675eb9119f3f4edb81888b6874bc1953f91e0b1d4f440",
                "sha256:17c0e467ade9bda685d5ac7f5fa729d8d3e76b23195471adae2d6a6941bd2c18",
                "sha256:1f27b5322ac4067e67c8f9378b41c746d8feac8bdd0e0ffede5324667b8a075c",
                "sha256:22d43376ee0acd547f3149b9ec12eec2f0ca4a6ab2f61753c5b29bb3e795ac4d",
                "sha256:2ad3ec9a748a8943e6eb4358201f7e1c12ede35f510b1a2221b70af4bb64295c",
                "sha256:301c00cf5e60e08e04d842fc47df641d4a181e651c7135c50dc2762ffe293dbd",
                "sha256:39a664e3d26ea854211867d20ebcc8023257c1800ae89773cbba9f9e97bae036",
                "sha256:51bf49c0cd1d52be0a240aa66f3458afc4b95d8993d2d04f0d91fa60c10af6cd",
                "sha256:78a63d2df1d947bd9d1b11d35564c2f9e4b57898aae4626638056ec1a231c40c",
                "sha256:7cd1328e5bdf0dee621912f5833648e2daca72e3839ec1d6695e91089625f0b4",
                "sha256:8355fc10fd33a5a70981a5b8a0de51d10af3688d7a9e4a34fcc8fa0d7467bb7f",
                "sha256:8c79d7cf86d049d0c5089231a5bcd31edb03555bd93d81a16870aa98c6cfb79d",
                "sha256:91b8d6768a75247026e951dce3b2aac79dc7e78622fc148329135ba189813584",
                "sha256:94c15ca4e52671a59219146ff584488907b1f9b3fc232622b47e2cf832e94fb8",
                "sha256:98dcbc02e39b1658dc4b4508442a560fe3ca5ca0d989f0df062534e5ca3a5c1a",
                "sha256:a64403f634e5ffdcd85e0b12c08f04b3080d3e840aef118721021f9b48fc1460",
                "sha256:bc6e8da415f359b578b00bcfb1d08411c96e9a97f9e6c7adada554a0812a6cc6",
                "sha256:bdc9febce3e68b697d931941b263c59e0c74e8f18861f4064c1f712562903411",
                "sha256:c1ba66c48b19cc9c2975c0d354f24058888cdc674bebadceb3cdc9ec403fb5d1",
                "sha256:c9f707b5bb73bf277d812ded9896f9512a43edff72712f31667d0a8c2f8e71ee",
                "sha256:d5422d6a1ea9b15577a9432e26608c73a78faf0b9039437b075cf322c92e98e7",
                "sha256:e5d5420053bbb3dd64c30e58f9363d7a9c27444c3648e61460c1237f9ec3fa14",
                "sha256:e868b0389c5ccfc092031a861d4e158ea164d8b7fdbb10e3b5689b4fc6498df6",
                "sha256:efd9d3abe5774404becdb0748178b48a218f1d8c44e0375475732211ea47c67e",
                "sha256:f8c02ec3c4c4fcb718fdf89a6c6f709b14949408e8cf2a2be5bfa9c49548fd85",
                "sha256:ffcf105ecdd9396e05a8e58e81faaaf34d3f9875f137c7372450baa5d77c9a54"
            ],
            "index": "pypi",
            "version": "==1.23.3"
        }
    },
    "windows": {
        "numpy": {
            "hashes": [
                "sha256:0791fbd1e43bf74b3502133207e378901272f3c156c4df4954cad833b1380207",
                "sha256:1ce7ab2053e36c0a71e7a13a7475bd3b1f54750b4b433adc96313e127b870887",
                "sha256:2d487e06ecbf1dc2f18e7efce82ded4f705f4bd0cd02677ffccfb39e5c284c7e",
                "sha256:37431a77ceb9307c28382c9773da9f306435135fae6b80b62a11c53cfedd8802",
                "sha256:3e1ffa4748168e1cc8d3cde93f006fe92b5421396221a02f2274aab6ac83b077",
                "sha256:425b390e4619f58d8526b3dcf656dde069133ae5c240229821f01b5f44ea07af",
                "sha256:43a8ca7391b626b4c4fe20aefe79fec683279e31e7c79716863b4b25021e0e74",
                "sha256:4c6036521f11a731ce0648f10c18ae66d7143865f19f7299943c985cdc95afb5",
                "sha256:59d55e634968b8f77d3fd674a3cf0b96e85147cd6556ec64ade018f27e9479e1",
                "sha256:64f56fc53a2d18b1924abd15745e30d82a5782b2cab3429aceecc6875bd5add0",
                "sha256:7228ad13744f63575b3a972d7ee4fd61815b2879998e70930d4ccf9ec721dce0",
                "sha256:9ce7df0abeabe7fbd8ccbf343dc0db72f68549856b863ae3dd580255d009648e",
                "sha256:a911e317e8c826ea632205e63ed8507e0dc877dcdc49744584dfc363df9ca08c",
                "sha256:b89bf9b94b3d624e7bb480344e91f68c1c6c75f026ed6755955117de00917a7c",
                "sha256:ba9ead61dfb5d971d77b6c131a9dbee62294a932bf6a356e48c75ae684e635b3",
                "sha256:c1d937820db6e43bec43e8d016b9b3165dcb42892ea9f106c70fb13d430ffe72",
                "sha256:cc7f00008eb7d3f2489fca6f334ec19ca63e31371be28fd5dad955b16ec285bd",
                "sha256:d4c5d5eb2ec8da0b4f50c9a843393971f31f1d60be87e0fb0917a49133d257d6",
                "sha256:e96d7f3096a36c8754207ab89d4b3282ba7b49ea140e4973591852c77d09eb76",
                "sha256:f0725df166cf4785c0bc4cbfb320203182b1ecd30fee6e541c8752a92df6aa32",
                "sha256:f3eb268dbd5cfaffd9448113539e44e2dd1c5ca9ce25576f7c04a5453edc26fa",
                "sha256:fb7a980c81dd932381f8228a426df8aeb70d59bbcda2af075b627bbc50207cba"
            ],
            "index": "pypi",
            "version": "==1.22.4"
        }
    }
}

Then you can install those specific platform lock sections: pipenv sync --categories windows

@matteius for that example yes, it just points out that each platform could have a totally unique dependency, like mac = 1.0, windows = 2.0, linux=3.0.  You can't always simplify :) So the poetry way of maintaining all the requirements and re-processing them during sync is more flexible

@thehesiod The problem is you cannot create the pipenv locks on the system you are not on for transitive dependencies or sdists that need to be built on that specific platform, so maintaining all of the requirements in one section is less practical to how pipenv utilizes the pip resolver.

@matteius ya, it would be nice to have the lockfiles be per arch, perhaps like Pipfile.w32.lock or something. Given you can have runtime dynamic dependencies it makes more sense to have one lockfile per arch, perhaps like Pipfile.darwin_x86_64.lock or something.  Actually I just found a counterpoint with poetry, it's unable to lock if not all platforms have valid scenarios, like we don't do win32, but because of this line it fails: https://github.com/PyCQA/pylint/blob/v2.15.2/pyproject.toml#L45.

I've tried to find a way to detect if this could be an issue in my Pipfile.lock.  I think the following command detects this.  Wouldn't it?
pipenv run grep "Root-Is-Purelib: false" $(dirname $(dirname $(which python3)))/lib/python3*/site-packages * -R --include=WHEEL

Just wanted to update this thread that named package categories were released in October and some users have found it a good way to manage multi-platform dependencies for a single project (such as developers on different operating systems all using pytorch) -- https://pipenv.pypa.io/en/latest/basics/#specifying-package-categories
I would suggest trying to make use of package categories to solve these edge cases, as there are not current plans to support lock file per platform.

@matteius thanks for the update, however I think  this section of the doc should contain more details about how this should actually be used to support multiple platforms

This may be desired in some use cases where users only are installing groups specific to their system platform

Eg. How to define groups for arm64 and x86_64 and how to use them to install packages

@januszm That is a good suggestion to improve the docs around this -- I think in general the docs stand to be improved.
You may find this example helpful:
https://github.com/pypa/pipenv/issues/5455#issuecomment-1304063926
I'd also like inputs about other options or configuration variables that would help make using the named categories easier -- for example right now pipenv lock --categories="default dev arm64" would lock only those packages, but maybe an option to pipenv lock --exclude-categories=x86_64would be useful, and a config var that could be put into the.envthat always applies a categories or exclude-categories string to make working with thePipfile.lock` easier when working cross-platform.

Thanks, I'm not sure if I understand correctly how this will work, but does it mean that people working on different architectures will generate different sections of the Pipfile.lock but will not interrupt each others groups ? So if developer A adds numpy on x86_64, she changes Pipfile.lock, then developer B on Macbook M1 also adds numpy, arm64 group is added and Pipfile.lock contains both variants? (from now on all developers can pipenv sync and get numpy for their platform)

@matteius Thanks for sharing your release including the named categories all over the place. It's a nice feature but it does not solve the "multi-platform" problem. It's now possible to define packages per category but that's already all. I'm still facing quite similar problems like @januszm.
I have a setup with some tools in the dev-section of the Pipfile. It works great till those tools does not have platform-dependent dependencies. You might think that's quite rare but think about colorama. Almost every code-quality-tool like ( black, pytest, pylint, etc.) needs this package to print colors on windows system. This package is not required on linux systems. What will now happen if one user locks on windows and the other on linux? Exactly, every lock creates a new lock-file, one with and one without colorama. It's possible to solve this issue by adding colorama to the Pipfile with a platform-marker but there are other examples like keyring of twine where it not works because it includes several dependencies over multiple levels.
To keep all those packages in the lock-file, the --keep-outdated flag must be set but then it's almost impossible to keep the packages up-to-date or just upgrade one certain package.

Can I get some more examples of cross platform locking problems that don't involve wanting different versions of libraries (which technically can be handled by categories) -- I've been playing around with our resolver implementation and I see a way to specify the platforms to the finder we create in a new method for the finder I've worked on but I don't have great examples to test with.

Hi, of course. Please take a look at the following minimal example. I created a minimalistic Pipfile and executed pipenv lock --dev on windows and linux platform with latest version pipenv, version 2023.3.20. I attached the generated lock-files to this post, just remove the unnecessary suffixes.
[requires]
python_version = "3.8"

[dev-packages]
twine = "*"

[packages]
numpy = "*"

Pipfile.lock.win64.log
Pipfile.lock.linux.log

I believe I'm running into this as well: https://github.com/pypa/pipenv/issues/5723
I have a package which only works on Linux, but development is happening on an M1 Mac. Because pipenv is skipping the package entirely, there are no hashes in the lockfile. When I attempt to install --deploy using the lockfile on Linux, the install fails.

For colorama it looks like the issue is that it uses platform_system, while many other packages use sys_platform and they work on other platforms.
Why do those work differently?

X-posting this for visibility, a recent issue lead to me working on a path forward for cross platform dependencies, and  I think I have something that could stick.  https://github.com/pypa/pipenv/pull/5892
Its probably only consider sys_platform markers right now, but I think it makes sense to apply it to all marker types.
Please have a look ...  here is an example:
matte@LAPTOP-N5VSGIBD MINGW64 ~/Projects/pipenv-bug-demo (main)
$ cat Pipfile
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
requests = {version = "*", sys_platform = "== 'linux'"}
urllib3 = "*"
#requests = {version = "*", markers="sys_platform == 'linux'"}

[dev-packages]

[requires]
python_version = "3.11"

matte@LAPTOP-N5VSGIBD MINGW64 ~/Projects/pipenv-bug-demo (main)
$ cat Pipfile.lock
{
    "_meta": {
        "hash": {
            "sha256": "132a5eb6d6138353e2837c95af6700c90651a30015f73b576a8a0268573d3548"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.11"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "certifi": {
            "hashes": [
                "sha256:539cc1d13202e33ca466e88b2807e29f4c13049d6d87031a3c110744495cb082",
                "sha256:92d6037539857d8206b8f6ae472e8b77db8058fec5937a1ef3f54304089edbb9"
            ],
            "markers": "python_version >= '3.6' and sys_platform == 'linux'",
            "version": "==2023.7.22"
        },
        "charset-normalizer": {
            "hashes": [
                "sha256:04e57ab9fbf9607b77f7d057974694b4f6b142da9ed4a199859d9d4d5c63fe96",
                "sha256:09393e1b2a9461950b1c9a45d5fd251dc7c6f228acab64da1c9c0165d9c7765c",
                "sha256:0b87549028f680ca955556e3bd57013ab47474c3124dc069faa0b6545b6c9710",
                "sha256:1000fba1057b92a65daec275aec30586c3de2401ccdcd41f8a5c1e2c87078706",
                "sha256:1249cbbf3d3b04902ff081ffbb33ce3377fa6e4c7356f759f3cd076cc138d020",
                "sha256:1920d4ff15ce893210c1f0c0e9d19bfbecb7983c76b33f046c13a8ffbd570252",
                "sha256:193cbc708ea3aca45e7221ae58f0fd63f933753a9bfb498a3b474878f12caaad",
                "sha256:1a100c6d595a7f316f1b6f01d20815d916e75ff98c27a01ae817439ea7726329",
                "sha256:1f30b48dd7fa1474554b0b0f3fdfdd4c13b5c737a3c6284d3cdc424ec0ffff3a",
                "sha256:203f0c8871d5a7987be20c72442488a0b8cfd0f43b7973771640fc593f56321f",
                "sha256:246de67b99b6851627d945db38147d1b209a899311b1305dd84916f2b88526c6",
                "sha256:2dee8e57f052ef5353cf608e0b4c871aee320dd1b87d351c28764fc0ca55f9f4",
                "sha256:2efb1bd13885392adfda4614c33d3b68dee4921fd0ac1d3988f8cbb7d589e72a",
                "sha256:2f4ac36d8e2b4cc1aa71df3dd84ff8efbe3bfb97ac41242fbcfc053c67434f46",
                "sha256:3170c9399da12c9dc66366e9d14da8bf7147e1e9d9ea566067bbce7bb74bd9c2",
                "sha256:3b1613dd5aee995ec6d4c69f00378bbd07614702a315a2cf6c1d21461fe17c23",
                "sha256:3bb3d25a8e6c0aedd251753a79ae98a093c7e7b471faa3aa9a93a81431987ace",
                "sha256:3bb7fda7260735efe66d5107fb7e6af6a7c04c7fce9b2514e04b7a74b06bf5dd",
                "sha256:41b25eaa7d15909cf3ac4c96088c1f266a9a93ec44f87f1d13d4a0e86c81b982",
                "sha256:45de3f87179c1823e6d9e32156fb14c1927fcc9aba21433f088fdfb555b77c10",
                "sha256:46fb8c61d794b78ec7134a715a3e564aafc8f6b5e338417cb19fe9f57a5a9bf2",
                "sha256:48021783bdf96e3d6de03a6e39a1171ed5bd7e8bb93fc84cc649d11490f87cea",
                "sha256:4957669ef390f0e6719db3613ab3a7631e68424604a7b448f079bee145da6e09",
                "sha256:5e86d77b090dbddbe78867a0275cb4df08ea195e660f1f7f13435a4649e954e5",
                "sha256:6339d047dab2780cc6220f46306628e04d9750f02f983ddb37439ca47ced7149",
                "sha256:681eb3d7e02e3c3655d1b16059fbfb605ac464c834a0c629048a30fad2b27489",
                "sha256:6c409c0deba34f147f77efaa67b8e4bb83d2f11c8806405f76397ae5b8c0d1c9",
                "sha256:7095f6fbfaa55defb6b733cfeb14efaae7a29f0b59d8cf213be4e7ca0b857b80",
                "sha256:70c610f6cbe4b9fce272c407dd9d07e33e6bf7b4aa1b7ffb6f6ded8e634e3592",
                "sha256:72814c01533f51d68702802d74f77ea026b5ec52793c791e2da806a3844a46c3",
                "sha256:7a4826ad2bd6b07ca615c74ab91f32f6c96d08f6fcc3902ceeedaec8cdc3bcd6",
                "sha256:7c70087bfee18a42b4040bb9ec1ca15a08242cf5867c58726530bdf3945672ed",
                "sha256:855eafa5d5a2034b4621c74925d89c5efef61418570e5ef9b37717d9c796419c",
                "sha256:8700f06d0ce6f128de3ccdbc1acaea1ee264d2caa9ca05daaf492fde7c2a7200",
                "sha256:89f1b185a01fe560bc8ae5f619e924407efca2191b56ce749ec84982fc59a32a",
                "sha256:8b2c760cfc7042b27ebdb4a43a4453bd829a5742503599144d54a032c5dc7e9e",
                "sha256:8c2f5e83493748286002f9369f3e6607c565a6a90425a3a1fef5ae32a36d749d",
                "sha256:8e098148dd37b4ce3baca71fb394c81dc5d9c7728c95df695d2dca218edf40e6",
                "sha256:94aea8eff76ee6d1cdacb07dd2123a68283cb5569e0250feab1240058f53b623",
                "sha256:95eb302ff792e12aba9a8b8f8474ab229a83c103d74a750ec0bd1c1eea32e669",
                "sha256:9bd9b3b31adcb054116447ea22caa61a285d92e94d710aa5ec97992ff5eb7cf3",
                "sha256:9e608aafdb55eb9f255034709e20d5a83b6d60c054df0802fa9c9883d0a937aa",
                "sha256:a103b3a7069b62f5d4890ae1b8f0597618f628b286b03d4bc9195230b154bfa9",
                "sha256:a386ebe437176aab38c041de1260cd3ea459c6ce5263594399880bbc398225b2",
                "sha256:a38856a971c602f98472050165cea2cdc97709240373041b69030be15047691f",
                "sha256:a401b4598e5d3f4a9a811f3daf42ee2291790c7f9d74b18d75d6e21dda98a1a1",
                "sha256:a7647ebdfb9682b7bb97e2a5e7cb6ae735b1c25008a70b906aecca294ee96cf4",
                "sha256:aaf63899c94de41fe3cf934601b0f7ccb6b428c6e4eeb80da72c58eab077b19a",
                "sha256:b0dac0ff919ba34d4df1b6131f59ce95b08b9065233446be7e459f95554c0dc8",
                "sha256:baacc6aee0b2ef6f3d308e197b5d7a81c0e70b06beae1f1fcacffdbd124fe0e3",
                "sha256:bf420121d4c8dce6b889f0e8e4ec0ca34b7f40186203f06a946fa0276ba54029",
                "sha256:c04a46716adde8d927adb9457bbe39cf473e1e2c2f5d0a16ceb837e5d841ad4f",
                "sha256:c0b21078a4b56965e2b12f247467b234734491897e99c1d51cee628da9786959",
                "sha256:c1c76a1743432b4b60ab3358c937a3fe1341c828ae6194108a94c69028247f22",
                "sha256:c4983bf937209c57240cff65906b18bb35e64ae872da6a0db937d7b4af845dd7",
                "sha256:c4fb39a81950ec280984b3a44f5bd12819953dc5fa3a7e6fa7a80db5ee853952",
                "sha256:c57921cda3a80d0f2b8aec7e25c8aa14479ea92b5b51b6876d975d925a2ea346",
                "sha256:c8063cf17b19661471ecbdb3df1c84f24ad2e389e326ccaf89e3fb2484d8dd7e",
                "sha256:ccd16eb18a849fd8dcb23e23380e2f0a354e8daa0c984b8a732d9cfaba3a776d",
                "sha256:cd6dbe0238f7743d0efe563ab46294f54f9bc8f4b9bcf57c3c666cc5bc9d1299",
                "sha256:d62e51710986674142526ab9f78663ca2b0726066ae26b78b22e0f5e571238dd",
                "sha256:db901e2ac34c931d73054d9797383d0f8009991e723dab15109740a63e7f902a",
                "sha256:e03b8895a6990c9ab2cdcd0f2fe44088ca1c65ae592b8f795c3294af00a461c3",
                "sha256:e1c8a2f4c69e08e89632defbfabec2feb8a8d99edc9f89ce33c4b9e36ab63037",
                "sha256:e4b749b9cc6ee664a3300bb3a273c1ca8068c46be705b6c31cf5d276f8628a94",
                "sha256:e6a5bf2cba5ae1bb80b154ed68a3cfa2fa00fde979a7f50d6598d3e17d9ac20c",
                "sha256:e857a2232ba53ae940d3456f7533ce6ca98b81917d47adc3c7fd55dad8fab858",
                "sha256:ee4006268ed33370957f55bf2e6f4d263eaf4dc3cfc473d1d90baff6ed36ce4a",
                "sha256:eef9df1eefada2c09a5e7a40991b9fc6ac6ef20b1372abd48d2794a316dc0449",
                "sha256:f058f6963fd82eb143c692cecdc89e075fa0828db2e5b291070485390b2f1c9c",
                "sha256:f25c229a6ba38a35ae6e25ca1264621cc25d4d38dca2942a7fce0b67a4efe918",
                "sha256:f2a1d0fd4242bd8643ce6f98927cf9c04540af6efa92323e9d3124f57727bfc1",
                "sha256:f7560358a6811e52e9c4d142d497f1a6e10103d3a6881f18d04dbce3729c0e2c",
                "sha256:f779d3ad205f108d14e99bb3859aa7dd8e9c68874617c72354d7ecaec2a054ac",
                "sha256:f87f746ee241d30d6ed93969de31e5ffd09a2961a051e60ae6bddde9ec3583aa"
            ],
            "markers": "python_full_version >= '3.7.0' and sys_platform == 'linux'",
            "version": "==3.2.0"
        },
        "idna": {
            "hashes": [
                "sha256:814f528e8dead7d329833b91c5faa87d60bf71824cd12a7530b5526063d02cb4",
                "sha256:90b77e79eaa3eba6de819a0c442c0b4ceefc341a7a2ab77d7562bf49f425c5c2"
            ],
            "markers": "python_version >= '3.5' and sys_platform == 'linux'",
            "version": "==3.4"
        },
        "requests": {
            "hashes": [
                "sha256:58cd2187c01e70e6e26505bca751777aa9f2ee0b7f4300988b709f44e013003f",
                "sha256:942c5a758f98d790eaed1a29cb6eefc7ffb0d1cf7af05c3d2791656dbd6ad1e1"
            ],
            "markers": "python_version >= '3.7' and sys_platform == 'linux'",
            "version": "==2.31.0"
        },
        "urllib3": {
            "hashes": [
                "sha256:8d22f86aae8ef5e410d4f539fde9ce6b2113a001bb4d189e0aed70642d602b11",
                "sha256:de7df1803967d2c2a98e4b11bb7d6bd9210474c46e8a0401514e3a42a75ebde4"
            ],
            "index": "pypi",
            "markers": "python_version >= '3.7'",
            "version": "==2.0.4"
        }
    },
    "develop": {}
}

`

There are on-going actions of pipenv:
https://github.com/pypa/pipenv/issues/5561#issuecomment-1699012985

The started off using pipenv 2022.9.21 and used the --skip-lock option which defeated one of the main reasons to use pipenv.  So I just recently upgraded to pipenv 2024.0.1 and am trying to use the lock files as best practice by checking them into my source repo.  But if lock files are not cross platform, they are no good.  I have the same problem as everyone else, develop on M1 mac or Windows, deploy to linux in cloud.  It has been almost 1 year since this thread has been updated.  What is the current status of this issue?

I'd love to hear more about this being solved by pipenv itself. In the meantime, see the last approach here with “packages categories” which may help you work around the problem.
https://github.com/pypa/pipenv/issues/5723#issuecomment-1580834717

It is a challenging problem to solve--would love to support a reasonable solution without just going back to extra-index-urls which was the source of the disputed SEV vulnerability regarding package confusion attacks, the very thing I spent a lot of time considering how to prevent in pipenv which is how we end up here.   I don't have a ton of excess time currently to devote to a multi-platform solution but I am supportive of finding one with the community.    I think it would take some serious contributions from someone to get it across the finish line.

My current lazy plan is to NOT commit the lock files into source control and execute the lock during the CI build.  I guess that is essentially the same as using --skip-lock.  Then I will pin certain versions of dependencies to block them from auto-updating within the Pipfile itself as opposed to relying on the lock file to pin everything.
Reading through this thread, my favorite option was the idea to specify which platforms the Pipfile should support.  This would tell pipenv which platforms to lock.  I don't have a lot of internal knowledge on how Pypi works, but docker is able to pull and run images for a platform different than the host by specifying a --platform switch.  I am assuming this user specified platform is used in the API queries made to docker hub to pull down available images.  I would have assumed that the code that reads all the PyPI indices (public and private) includes the platform allowing pipenv to run the dependency mechanism multiple times for each platform listed in the Pipfile.

would have assumed that the code that reads all the PyPI indices (public and private) includes the platform allowing pipenv to run the dependency mechanism multiple times for each platform listed in the Pipfile.

I think that is what it does do, except for packages that don't provide pre-built wheels, that is when multi-platform is really problematic because you typically cannot build the sdist for the alternative OS to obtain the hashes when locking.   I believe that is why some have proposed lock file sections, or overrides or even separate files specific to platforms.   In theory something like that may be  tenable, but its a complex landscape that someone needs to dig deeply into to improve the conditions.

Are the hashes just to prevent tampering?  If so, I would be happy with a lock file that does not include hashes and instead just records the versions of everything.  This would at least prevent a dependency from auto-upgrading when a new release comes out, like NumPy 2.x did very recently and broke our builds.  Would a simplified lock file with just versions and no hashes make the problem easier to solve?

@scastria that is correct --- One thing to maybe tryin the interim is have the pipeline generate the requirements file from the lock file you use locally (possibly with hashes) and see if your CI can install with just pip install -r requirements.txt which would be quite similar to what you are describing.


Allow multiple trailing zeros in floating point literals

Currently multiple trailing zeros are removed. These are sometimes used for alignment in e.g. literal arrays. Currently
 [
-    0.100 0.123
-    0.123 0.100
+    0.1 0.123
+    0.123 0.1
 ]

Perhaps this should be allowed, or atleast be disabled inside array literals?

With JuliaFormatter, I have had to do:
      #! format: off
      arr[:, :] .= [
      #  foobarbaz   baz    qux
         34.36       5.89   20.28   # class_a
          0.29       0.00    0.00   # class_b
      ]
      #! format: on

Specifically, here we wanted to align the data along with the comment names.
Maybe just having a way to turn off formatting for a section would be a good feature to have?

I think it should be sufficient to right justify columns and allow trailing zeros to pad with.


Windows 11 Docker setup documentation incorrect

Documentation says that for Windows users in docker preferences we should set RAM minimum 4GB, but I changed this manually with wsl changing vm.max_map_count to at least 262144.

First I installed wsl with Ubuntu backend
With wsl terminal added following line to /etc/sysctl.conf:
vm.max_map_count=262144
Then with "sudo sysctl -p" command reloaded.

Closed by https://github.com/opensearch-project/documentation-website/pull/5077


LU publishing failed when contains pattern with perbuilt entity

Describe the bug

LU publishing failed when contains patterns with perbuilt entity. E.g:
- (create|book|schedule) (a|an) (meeting|appointment|event) [with {personName}] (at|for|on) [{FromDate}] [{FromTime}]
@ prebuilt personName

The reason is the prebuilt entity will be removed when cross train.
Version

Browser

[ ] Chrome
[ ] Safari
[ ] Firefox
[ ] Edge

OS

[ ] macOS
[ ] Windows
[ ] Ubuntu

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior

Screenshots

Additional context

Synced with Yue. This is the background.

pattern with prebuilt entity can work for a single dialog
But it will hit some errors during #_interruption publish

One more simple repro case

abc brenda
abc {@personName}
@ prebuilt personName

we can use regexPattern="{.*?}" probably to detect an entity in pattern

BF-CLI fix is here https://github.com/microsoft/botframework-cli/pull/758. If we think this is P0 blocker of R9 release for composer, then BF-CLI should let above fix PR in before R9. Otherwise, we can target R10. Any thoughts @boydc2014

BF-CLI fix is here microsoft/botframework-cli#758. If we think this is P0 blocker of R9 release for composer, then BF-CLI should let above fix PR in. Otherwise, we can target R10. Any thoughts @boydc2014 @hibrenda

I think we have chance to take that in CLI and cut a new RC.

BF-CLI fix is merged into 4.9 RC, please update the package in composer when next RC is online @lei9444


Make auto-loading .env files optional with a setting to turn it off

The Python extension looks for and loads the .env file within a workspace, which loads those variables into the environment for tests and the integrated terminal. This feature should be made optional with a setting to turn it off. The .env file in a workspace often is not the settings someone would like to use when running unit tests, so tests will fail with those settings. Without a way to turn it off, I have to either comment out the .env file before running unit tests, or go to another terminal outside of VS Code to run my tests.
Please make the auto-loading of .env files in a workspace optional with a setting to turn it off.

Hi! To clarify is this primarily with tests you have this problem or with all parts of your setup?

Yeah it mostly becomes a problem when I run tests, both from within the VS Code UI and through the integrated terminal. In both instances, they have the environment variables loaded but those variables mess up the tests. The .env file is read when my app starts up so I don't see a need to have it auto-loaded into the env (at least not for any of my use cases).


[SMALLFIX] Instream options fix

Restore conf after altering it.

LGTM

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/6572/Failed Tests: 0
Test FAILed.


Add some fields to service.CommandTreeNode

I need the following for nodes that represent groups:
Path.Command to use for thumbnail (empty if none should be shown) - this can be an interim solution until we figure something out that works better with Vulkan
Path.Command to use for texture, shader, memory, etc views, when a group is selected
Index of first command and number of commands for display purposes.

Path.Command to use for thumbnail (empty if none should be shown) - this can be an interim solution until we figure something out that works better with Vulkan

Instead of adding a field to the CommandTreeNode, I've added CommandTreeNode support to path.Thumbnail - see 9b59ad7.

Path.Command to use for texture, shader, memory, etc views, when a group is selected
Index of first command and number of commands for display purposes.

Restructured the CommandTreeNode to always have a command field in dcf6ab4. I think we need to discuss the "number of commands" bit. Remind me to bring it up in today's meeting, perhaps?

re: 9b59ad7 - So we are now assuming there will always be a relevant thumbnail for a group? We may want to add an error type that says that the thumbnail should be ignored.
re: dcf6ab4 - This helps with selection, great. I still need the path to the first command in order to show the index for the group.
re: counts - I think they are useful, it makes it easy to find a frame that all of a sudden does a lot of extra stuff, for example. I understand that, especially for Vulkan, not all commands are equal, but it's still an overall helpful perf measure. I envision the following hierarchy for Vulkan, which makes sense to me:
frame x (57 commands)
- 4400: vkWhatever
- 4401: vkSomethingElse
- ...
- 4455: vkQueueSubmit (23 subcomands)
  - 4455.0: vkCmdWhatever
  - 4455.1: vkCmdMoarStuff
  - ...
  - 4455.22: vkSoMuchFun
- 4456: vkWaitForFences

Even if subcommands have subcommands it makes sense to me.

So we are now assuming there will always be a relevant thumbnail for a group

I would have thought you'd get an ErrDataUnavailable in this case, but I could be wrong.

This helps with selection, great. I still need the path to the first command in order to show the index for the group.

Humm, let me think about that a little.

re: counts

The trouble is counting is expensive, and it can undo all the laziness we're trying to do. I think this is a Nice To Have, and maybe we should revisit it.


Add deduplicate results operation

Currently if you execute an GetAdjacentEntitySeeds operation on accumulo if there are duplicate edges then duplicate entity seeds will be returned. Other operations can also return duplicate results.
To fix this we could deduplicate results before returning them to users. Doing this could be computationally expensive so it should be optional via an Operation Option.

To use this new feature, add the following operation option:
accumulostore.operation.deduplicate_elements = "true"
This can be used when executing any operation that returns an iterable on an accumulo store.

Merged into develop


add popup with form when click on the table cell

Hi) I am new here)
Can you help to find the way to add popup with form when click on the table cell - onSelectSlot?

You would put that functionality in your onSelectSlot method.


chore: bdd-sbhg-1573038476 to 0.0.1

chore: Promote bdd-sbhg-1573038476 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Unable to build release build on Ubuntu 18.04 Bionic

I'm trying to build a release build from Git (at revision 2a16bc6b644e6fc8a309f0b0f31fd3592a02bf1a) on Ubuntu 18.04 Bionic.
I'm observing:
[nelhage@hw3:/data/home/nelhage/code/sorbet]$ ./bazel build --config=release-linux //...                                                    [88/552]
WARNING: The following configs were expanded more than once: [static-libs, lto, backtracesymbols, versioned, lto-linux, release-common]. For repeatable flags, repeats are counted twice and may lead to unexpected behavior.
[snip intermediate output]
INFO: Analyzed 2559 targets (1 packages loaded, 562 targets configured).
INFO: Found 2559 targets...
ERROR: /data/home/nelhage/code/sorbet/test/fuzz/BUILD:11:1: Linking of rule '//test/fuzz:fuzz_dash_e_impl' failed (Exit 1)
ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol absl::container_internal::EmptyGroup()::empty_group; recompile with -fPIC
>>> defined in lto.tmp
>>> referenced by raw_hash_set.h:1773 (external/com_google_absl/absl/container/internal/raw_hash_set.h:1773)
>>>               lto.tmp:(sorbet::realmain::options::Options::Options())

ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol vtable for sorbet::OSFileSystem; recompile with -fPIC
>>> defined in bazel-out/k8-opt/bin/test/fuzz/_objs/fuzz_dash_e_impl/fuzz_dash_e.pic.o
>>> referenced by FileSystem.h:44 (./common/FileSystem.h:44)
>>>               lto.tmp:(sorbet::realmain::options::Options::Options())

ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol typeErrorsConsole; recompile with -fPIC
>>> defined in lto.tmp
>>> referenced by memory:3805 (external/llvm_toolchain/bin/../include/c++/v1/memory:3805)
>>>               lto.tmp:(buildInitialGlobalState())

ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol typeErrorsConsole; recompile with -fPIC
>>> defined in lto.tmp
>>> referenced by memory:3803 (external/llvm_toolchain/bin/../include/c++/v1/memory:3803)
>>>               lto.tmp:(buildInitialGlobalState())
[many more]

I think this is fixed, but I'm not sure when it was fixed (at least, I regularly build on 20.04 without issue these days). Feel free to reopen if I'm mistaken.


Add bill pay instructions

add to give page

@keelyjay If you write up some instructions for bill pay, I can definitely add this to the page.

Can you copy from ben’s Thursday email
Sent from my iPhone

On Jul 28, 2018, at 9:07 PM, Adam Garrett-Harris<EMAIL_ADDRESS>wrote:
@keelyjay If you write up some instructions for bill pay, I can definitely add this to the page.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Sure.
Give to Lifestone through your checking account online.  All you need is our mailing address:
Lifestone Church 5526 W. 13400 S. #352 Herriman, UT 84096

@keelyjay Here is an idea of what I'm thinking for the giving page:


GCC generates non-position-independent code under -cmodel=medany

The objects we generate from GCC for the medium code model, aka -cmmodel=medany, are not position independent unless -fPIC is also passed.  This violates the psABI spec, which says under the medium code model section that "This code model is position independent."

@palmer-dabbelt What's GCC doing that's non-PIC?

Using PC-relative addressing modes to resolve absolute symbols -- I guess one could argue that's a linker problem or a compiler problem, but IMO the relocations are pretty clear about being PC-relative and thus it's a GCC bug.  One could imagine rejecting these at link time, but that would break existing use cases -- there's a bit about deprecating the weak undefined symbol trick, but all absolute symbols are equally broken.  Dropping these use cases might be the right thing to do, as there's certainly bugs here in binutils, but there are currently users of them without a suitable replacement (Linux, for one, but that specific use is somewhat silly).
One could imagine having something between -fPIC (ie, code suitable for shared libraries) and -mcmodel=medany (ie, position-independent but without the extra bits for shared libraries), maybe via either absolute-tolerant relocations (properly GOT or some other constant table) or by absolute-banning relocations (whether that breaks existing use cases or now).  IMO it's way too late in the release cycle to do that now,, though, so that leaves the only option to make GCC match the current spec being to drop the bad code gen modes (ie, "-mcmodel=medany -fno-PIC").
That's what I'd originally suggested, as I thought the spec was past the point where it could be changed, but nhe general consensus on the toolchain call today was that I should submit this as a spec bug.  I don't really care either way, just trying to figure out how to stop generating code that violates the spec.

@jrtc27 made the point that -mcmodel=medany -pie works just fine, which from simple examples GCC seems to be handling just fine.  To me, that does mean that medany is position-independent.
I don't think we should drop anything from this GCC release.

Isn't -fPIE the thing in between? It's basically the same, except it uses the GOT for anything that might require a copy relocation, though that's really an orthogonal thing.
Using absolute symbols is fine at link time, so long as they're within range (or, in the case of binutils, it can mangle your instructions to fix your bogus input). That doesn't make the input any less position-independent, it just means you made it position independent at link time, just like if you linked libfoo_pic.a into a position-dependent executable.
I don't think GCC's current behaviour is wrong here, other than the weak symbol issue that's already documented.

@jrtc27 would it make sense to clarify this with an informal note in the document?
E.g. "Note, that although the generated code is position independent, it might still be necessary to enable additional compiler flags (e.g. -fPIC) when building position-independent ELF objects (e.g. shared libraries)."

I sent a GCC patch to describe the behavior.  IMO it's always better to have stuff in the spec than just in review comments, but we've got a lot of stuff in the comments so I'm fine either way.


Optional dependencies that use the dep: syntax are listed as features

For example: https://docs.rs/crate/icu_datagen/1.1.0/features
simple_logger, eyre, and clap are not features, because they are referenced by the bin feature using the dep: syntax. Any attempt to use them will result in a Cargo error. These should not be listed as features.

Oh nice, cargo metadata now normalizes optional-dependencies-as-features for us:
> cargo new foo && cd foo
     Created binary (application) `foo` package
> cargo add serde --optional
    Updating crates.io index
      Adding serde v1.0.152 to optional dependencies.
             Features:
             + std
             - alloc
             - derive
             - rc
             - serde_derive
             - unstable
# it shows a feature for the implicit optional dependency feature
> cargo metadata --format-version 1 | jq -r '.packages[] | select(.name == "foo") | .features'
{
  "serde": [
    "dep:serde"
  ]
}
# when `dep:` is used it stops showing the implicit feature and only shows the explicit one
> echo '[features]\nserde2 = ["dep:serde"]' >> Cargo.toml
> cargo metadata --format-version 1 | jq -r '.packages[] | select(.name == "foo") | .features'
{
  "serde2": [
    "dep:serde"
  ]
}

We are already parsing the cargo metadata output, we just need to stop manually including optional dependencies (older cargo from before dep: was stabilized didn't do this normalization for us).

Could the database be cleaned up to fix existing crates?

If we do a rebuild for a release this data will be updated IIRC. Once it's deployed I will queue a rebuild for icu_datagen 1.1.*. (Feel free to mention if there are other crates that also need it).

We do in fact have a few more...
databake
icu_calendar
icu_capi
icu_casemapping
icu_collator
icu_collections
icu_compactdecimal
icu_datagen
icu_datetime
icu_decimal
icu_displaynames
icu_list
icu_locid
icu_locid_transform
icu_normalizer
icu_plurals
icu_properties
icu_provider
icu_provider_adapters
icu_provider_fs
icu_relativetime
icu_segmenter
icu_testdata
icu_timezone
yoke
zerofrom
zerovec

@Nemo157 I just deployed the change.

apart from rebuilding I could imagine there is a pure SQL way of fixing this, right? Or am I missing something?

( I'm happy to dig into it if that's the case)

Nope, we don't have enough build capacity to rebuild everything on every release. I think there should be a way to do this via sql, I'll try to come up with a script.

I didn't manage to come up with a sql script, but it looks like all the listed crates have had new releases themselves so the latest versions should be correct.


Container doesn't appear to be run-able as non-root despite PR to fix it

Describe the bug
The container seems to still want to run as root despite using 1.7.1 docker tag.
To Reproduce
Steps to reproduce the behavior:

Pull ghcr.io/jorenn92/maintainerr:1.7.1
Change entry point to sh
Run cat /etc/supervisord.conf
See that it's still set to root.

Expected behavior
It should list user as node instead of root.
 As it's a breaking change, the upcoming release that incorporates this pull request will be version 2.0.
If you're eager to use it immediately, you can utilize the 'ghcr.io/jorenn92/maintainerr:main' image. Keep in mind that this image may break at any time.

The non-root pull request has been merged into the main branch but hasn't been released yet. As it's a breaking change, the upcoming release that incorporates this pull request will be version 2.0.

Technically it was released at some point as 1.7.1, as otherwise the specific sha with it wouldn't work either aka '1.7.1@sha256:0a826f9b33a53e7a241d0b2d8ba2533c6efb978067d149c4f6801a657853ee53'

The non-root pull request has been merged into the main branch but hasn't been released yet. As it's a breaking change, the upcoming release that incorporates this pull request will be version 2.0.

Technically it was released at some point as 1.7.1, as otherwise the specific sha with it wouldn't work either aka 1.7.1@sha256:0a826f9b33a53e7a241d0b2d8ba2533c6efb978067d149c4f6801a657853ee53 so why's that?

Oh yeah, I switched CI from Jenkins to GitHub Actions. When testing the 'release' pipeline, it accidentally pushed an image of 'main' as version 1.7.1. I quickly fixed it, even before it was mentioned in the documentation that images are available on ghcr.io as well. I didn’t think much if it at the time, but that’s probably the reason.


Project Microsoft.AspNetCore.StaticFiles does not have a lock file

Just trying to dotnet run StaticFileSample and then

Project Microsoft.AspNetCore.StaticFiles does not have a lock file. Please run "dotnet restore" to generate a new lock file.
Project Microsoft.AspNetCore.StaticFiles does not have a lock file. Please run "dotnet restore" to generate a new lock file.

dotnet restore doesn`t help.

How about running Build in the solution root?

Downloading KoreBuild from https://github.com/aspnet/KoreBuild/archive/dev.zip
Building /home/rocketlife/Documents/Projects/StaticFiles
dotnet-install: Downloading https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.0-preview2-003121/dotnet-dev-ubuntu-x<IP_ADDRESS>-preview2-003121.tar.gz
dotnet-install: Extracting zip
dotnet-install: Adding to current process PATH: /home/rocketlife/.dotnet. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.
Failed to initialize CoreCLR, HRESULT: 0x80131500
Failed to initialize CoreCLR, HRESULT: 0x80131500
Cannot open assembly '.build/Sake/0.2.2/tools/Sake.exe': No such file or directory.

On windows 10 x64 works fine

@YaroslavSchubert Make sure to install all prereqs for Ubuntu.  See https://www.microsoft.com/net/core#ubuntu


Copy + Paste moves text inside rectangle

I have rectangle with text inside. When I select and copy them both text in copy is aligned to left top corner instead of being in the same position relative to rectangle.

This is likely related to https://github.com/excalidraw/excalidraw/pull/214
@abhikulshrestha22 could you look into it? cc @Fausto95

I was working on center it today, I will push something in a bit!


add crd dependency

Towards: giantswarm/giantswarm#20256
Basically run helm dependency update
$ helm dependency update ./helm/prometheus-operator-app
Getting updates for unmanaged Helm repositories...
...Successfully got an update from the "https://giantswarm.github.io/giantswarm-catalog/" chart repository
...Successfully got an update from the "https://grafana.github.io/helm-charts" chart repository
...Successfully got an update from the "https://prometheus-community.github.io/helm-charts" chart repository
...Successfully got an update from the "https://prometheus-community.github.io/helm-charts" chart repository
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "cowboysysop" chart repository
...Successfully got an update from the "default" chart repository
...Unable to get an update from the "kubernetes-charts" chart repository (https://kubernetes-charts.storage.googleapis.com/):
        failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden
...Successfully got an update from the "fairwinds-stable" chart repository
...Successfully got an update from the "playground-test" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 4 charts
Downloading kube-state-metrics from repo https://prometheus-community.github.io/helm-charts
Downloading prometheus-node-exporter from repo https://prometheus-community.github.io/helm-charts
Downloading grafana from repo https://grafana.github.io/helm-charts
Downloading prometheus-operator-crd from repo https://giantswarm.github.io/giantswarm-catalog/
Deleting outdated charts

NOTE: I add to publish v0.12.2 git tag for this to work. I'll overwrite it with next release.

  tarballURL: https://giantswarm.github.io/control-plane-test-catalog/prometheus-operator-app-0.12.2-865a69e34bc365dc3cbd1a6fdda582b2506ef885.tgz
  version: 0.12.2-865a69e34bc365dc3cbd1a6fdda582b2506ef885
status:
  appVersion: ""
  reason: 'invalid manifest error: (unable to build kubernetes objects from release
    manifest: unable to recognize "": no matches for kind "ServiceMonitor" in version
    "monitoring.coreos.com/v1")'
  release:
    status: invalid-manifest
  version: ""

This does not work helm does not install dependencies first.


Fix nameing of Namespaces to be more consistent

Figuring out the difference between a User and a USERNS
as well as Cgroup and CGROUPNS
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

LGTM

@rh-atomic-bot r=TomSweeneyRedHat

@rh-atomic-bot retry


Allow "show_progress_bar" and "convert_to_tensor" in DenseRetrievalExactSearch

This PR would allow enabling/disabling the progress bar when defining the DRES class, as well as specifying convert_to_tensor if needed.

Hi @xhluca, thanks for the PR. I saw this late but I already implemented it in my latest revamping of the BEIR repository code.
Thanks,
Nandan


White background on quotes obscures quote symbol

This was actually a book-level theme issue, not Peruse.


Very slow eval compared to pure nixpkgs and flake-parts

I tried flakelight today, and notice eval is very slow.
Write a small demo to show it.
pure nixpkgs:
$ hyperfine -w 1 'nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/nixpkgs'
Benchmark 1: nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/nixpkgs
  Time (mean ± σ):      1.677 s ±  0.035 s    [User: 0.695 s, System: 0.180 s]
  Range (min … max):    1.592 s …  1.715 s    10 runs

flake-parts:
$ hyperfine -w 1 'nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/flake-parts'
Benchmark 1: nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/flake-parts
  Time (mean ± σ):      1.659 s ±  0.029 s    [User: 0.687 s, System: 0.179 s]
  Range (min … max):    1.620 s …  1.710 s    10 runs

flakelight:
$ hyperfine -w 1 'nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/flakelight'
Benchmark 1: nix --option eval-cache false flake show github:azuwis/flakelight-eval-test/flakelight
  Time (mean ± σ):     20.198 s ±  0.973 s    [User: 9.464 s, System: 1.527 s]
  Range (min … max):   18.523 s … 22.064 s    10 runs

flakelight take 20s for a simple demo, 10 times slower compared to pure nixpkgs and flake-parts.
All use some nixpkgs version github:NixOS/nixpkgs/cfc3698c31b1fb9cdcf10f36c9643460264d0ca8.
nix-info -m

system: "aarch64-darwin"
host os: Darwin 23.2.0, macOS 14.2.1
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.18.1
channels(azuwis): ""
channels(root): ""
nixpkgs: /etc/nix/inputs/nixpkgs

Yeah, I can reproduce slow times with those examples. I'll take a look.
I'd expect more time due to building the overlay, but that should not take that long.

I've pushed commits that speed up evaluation. The largest portion of time was taken by the autodetection of the default package's name, which now should be much faster for most cases.
On my machine, the recent commits bring the measured time of your command down from 15s to around 2s.
Thanks for the report! Since the speed is now reasonable, and I've exhausted the obvious optimizations, I'll close this issue. Feel free to re-open if there is still an issue, or more optimization suggestions.


When will the software release. It's been in beta review for ages

Soon. We're gonna open source it in the next few weeks and then it'll be available for all.


Properly deal with hostedclusters that have a dot in the name

If a hostedcluster has a dot in its name, we currently fail to reconcile
it because we use the name as part of the namespace name and namespace
names do not allow dots.
Clusters with dots in their name end up being created by the periodic
jobs created by the release controller, because the release controller
uses the release as part of the prowjob name and we use the prowjob name
as stable identifier over steps to identify the cluster. Sample:
https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-hypershift-main-periodics-e2e-aws-pooled-periodic-conformance/1491754642944561152#1:build-log.txt%3A100

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm


Add method to get wavelength array from an Observation's FITS Header, and add wavelength label to GUI settings tab

Closes #372
Pull request checklist

[ ] Add a clear description of the change
[ ] Add any new tests needed
[ ] Run spell check on new text visible to user (documentation, GUI etc.)
[ ] Check any changes to requirements.txt are reflected in setup.py and conda-forge feedstock
[ ] Check code passes CI checks (run run_ci.sh or check GitHub Actions)

See CONTRIBUTING.md for more details.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

19 of 19 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 99.617%

Totals

Change from base Build<PHONE_NUMBER>0:
0.002%

Covered Lines:
3157

Relevant Lines:
3169

💛  - Coveralls


[BUG] Resources Is Loading (Stuck)

Hi, in my Launcher resources is stucking. Idk why, is anyone knows how to resolve?

use 3.3.6


Remove VOS support

VOS was only supported on HP-PARISC and Itanium, so remove it.

Related to #6232

PARISC and Itanium are still actively used architectures. I don't know much about vos, but am noticing that it wasn't mentioned in #6232.

No, #6232 wasn't a comprensive list of platforms to  unsupport.
The only VOS support is in the hacky RAND seeding (see the comment in rand_unix.c); do we still want to support that these days?

I posted to openssl-users nearly a month ago, https://mta.openssl.org/pipermail/openssl-users/2019-June/010772.html, and there was no comment.  Okay to move forward on this?

If you look at the PR, and this comment from a month ago, the only thing this really removes is seeding by repeatedly sampling a real-time clock.  Ugh

This is incomplete, there's still a vos-gcc config target in Configurations/10-main.conf.

the only thing this really removes is seeding

This is not true, it's not the only thing being removed

No it's not the only thing, but the use of "really" is perhaps an Americanism to mean "the only thing really of substance"  Additional commit pushed, thanks for catching it.

You and I value things differently, I find the removal of a config target substantial, no matter how old and ill updated it is.

But, I didn't remove the config target at the time I wrote the "really the only thing" :)

You kinda sorta did, since you removed the guessing code in config.

This goes against the stated compatibility plans so I'm closing this. If someone wants to recreate for a future release, feel free to adopt the branch. :)


[Enhancement] UX improvements

I am pretty much aware of the recommendation to only submit one bug/feature per issue. But that would make me a spammer. So, I decided to bundle them here.
Before I begin, I want to say (@IacobIonut01) that I really love it how this gallery app presents itself. You did an amazing job, and everything below is improvement suggestions, not criticism.

Overall the app doesn't seem updated for tablets (regardless of the material navigation option). everything looks oversized.
Album mode: rather than having 4 filters (recent,old, a-z, z-a), you could consider adding a second button next to it, for changing order direction (⇅). This way, you could add more filters, such as last modified, etc, without overloading the filters list)
Album mode: hanging the number of columns in grid view is limited to 3. On a tablet that's still not enough. Especially in landscape mode.
The pinch gesture for changing grid size (as mentioned in 2.) can very easy select/multiselect images instead of performing the intended operation. Perhaps you could also add a menu setting, for people who have difficulties with complex gestures (or if the gesture is behaving unpredictably).
Pictures in album are grouped by date and that cannot be changed. Perhaps adding different grouping (by type, for example),and no grouping, in an easily accessible menu, would  make sense.
You have a search field, which is really handy. But the app lacks a tags system. Now, I could search by date, but who remembers "PXL_20240513_104452414-01_portrait.jpg" ? Definitely not me. But giving tags to images, can make searching more relevant and useful.
Timeline: having quick access to certain grouping modes (by date, month, tags, etc), without having to always go in settings, would make the experience much better.
I like that the "edit" button opens directly the integrated editor. I would like to propose a second edit button  (edit with...), to allow the user to pick an external editor. Many apps, including Fossify Gallery have their edit button to call the app selector, but they lack a direct editing button. So, you see... The compromise is to either always have the app selector menu popping up, or to select one app to be "always ", but then to not be given the choice anymore. Having both an "edit" and an "edit with" buttons, would solve this issue.
Option to customize what actions are displayed on the screen in each viewing mode, and whether the action should be at the top or bottom of the screen.

The list is not complete. I mentioned Fossify Gallery; it has some really useful features, basic ones, but nonetheless useful. You may get inspired.
Lastly, the ap name. I get it: you want it to reflect the simplicity and the fact it does what it says, without frills. However, is so generic that is difficult to find. What about  "Jacob Gallery"? 😁...
Wishing you all the best!

Hi, thanks for all of the suggestions, I will clearly take them under consideration as I agree with each. Also about the naming of the app, I am planing a rebrand (Moments) with the 3.0.0 release - as you can see there's already some nightly releases on it, but still a lot is left to be done.

I just found this. Pretty sure there is no risk of confusion, but I thought you should know aboit it:
https://play.google.com/store/apps/details?id=com.gg.lovestory.moments

Hi there, I'm jumping in here with a few name suggestions in case the new name isn't yet set in stone: Gellary ("a" and "e" in "Gallery" have switched places), GallerII (II = Iacob Ionut; pronounced just like "Gallery"), Gallery01 (numbers from developer's GitHub username), Gallery+, Feathery (app is light as a feather, also sounds a bit like "Gallery").

If my opinion is of any importance, Gallerii with two lowercase i looks good and doesn't obscure what the app does.

I'm not yet decided on a new name, maybe the rebrand will come after the feature set of the app will be come more mature (a proper image/video editor etc)

I'm not yet decided on a new name, maybe the rebrand will come after the feature set of the app will be come more mature (a proper image/video editor etc)

This is the best way to approach this. Thank you for not rushing into things.


Deletion bug

Middle clicking the compactors out inventory to sort, delete the items
Sorter

The mod has been recently updated to MC 1.16, older versions are no longer supported.
I'm mass closing older issues to clear up clutter in the bug tracker.
If you find this issue still exists in the current version feel free to reopen it.

This still exists in 1.19.2


cannot load such file -- ci/reporter/core (LoadError)

I'm checking out this gem to test out my app in development. So far it's great, I just ran into one hiccup during installation: I ran gem install crawl and then attempted to crawl http://localhost:3000 --connections=1 --start=/ --verbose. I got "cannot load such file -- ci/reporter/core (LoadError)".
Once I ran gem install ci_reporter it was fixed. So should "ci_reporter" be in the gemspec?

Good catch, I don't think it is used, so removing it https://github.com/alphasights/crawl/pull/5


[FIX] Top Post Count Discourse Module

[x] I have read the Contributing Guide - https://github.com/RocketChat/Rocket.Chat/blob/develop/.github/CONTRIBUTING.md#contributing-to-rocketchat doc
[x] I have signed the CLA - https://cla-assistant.io/RocketChat/Rocket.Chat
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if applicable)
[ ] I have added necessary documentation (if applicable)
[x] Any dependent changes have been merged and published in downstream modules

Proposed changes (including videos or screenshots)

Made changes in the discourse module so that only the top N entries are stored in the CMS.
Included checks to make sure that the same TopPost does not populate the database.
On Every Call the excess old posts will be deleted and  new fresh TopPost will be added.

Issue(s)
Fixes : #21

@RonLek  @Sing-Li I have made the changes and have locally tested updating the data (with some dummy data) to maintain the top N posts only. Have also made sure that if the same post is fetched again, then it is not stored again in database. By default strapi will fetch posts in the order in which they are created. Hence we delete the first X stale posts and add ours to the CMS database after that. Let me know if there are any changes :smile:


Will TypL cover 100% of JS semantics?

Other projects like TypeScript struggle with providing ergonomic ways of typing code written in a functional style. And at least at some point, TypeScript wasn't expressive enough to type certain functional programming techniques at all. I'm not sure if this is still true but I suspect it is. TypL works a bit different though because it works on value-types instead of variables so I imagine it's more flexible.

Are there things in JS that you can do but are not possible for TypL to type?
How does TypL fair with regards to typing functional programming techniques?
Does TypL make tradeoffs that favor a particular style of coding?

I know TypL isn't done yet so I'm fine with the answers to refer to assumptions and goals for TypL.
Thanks!

+1 if it could validate off of JSDoc types, then you'd encourage people to document their code as well.

@getify Thanks!
With regards to documentation, could you see TypL supporting it's own documentation style? It would be amazing to include these details for runtime debugging or integrations with IDEs. Something like this?
/*
 * Description
 * This function checks if a number is an even number.
 *
 * Parameters
 * v - the value to check
 *
 * Returns
 * isValueEven - whether the value is even or not
*/
function isEven(v = number) {
   return bool`${ v % 2 == 0 }`;
}

Or maybe more programmatically (if needed):
function isEven(v = number) {
   return bool`${ v % 2 == 0 }`;
}
documentation (isEven, {
  description: 'This function checks if a number is an even number.',
  parameters: {
    v: 'the value to check'
  },
  returns: {
    'isValueEven': 'whether the value is even or not'
  }
})

With documentation being supplied by TypL. A function-based approach would be able to harness all of JS's features (importing, exporting, modularizing config object parts, etc). And returns could be simplified if we don't want a named return value (could be optional):
returns: 'whether the value is even or not'

I assume this would be a fairly big lift so I understand if this idea is not desirable because of it. But I do think JS is hurting for a modern, non-JSDoc documentation system in general. Might help the case for relevancy for TypL.

So we're talking about documentation more in terms of generating external documentation (like markdown pages or whatever) from the code than in terms of readability in the code itself?
I think having an extensible documentation system (one where automated documentation from code can be augmented by additional developer-supplied information) is useful. I'm not sure how much of that would be TypL specific, though. I mean, I could almost see that as its own project where it could ingest types (either TS or TypL or Flow or whatever) and then read additional documentation hints from the code, and produce nice customized documentation. That would be a really neat project.
I am not saying TypL couldn't tackle that, but I'm saying that I don't know if we should limit it to being only TypL. Perhaps that could be an interesting sub-project here, and then eventually spins out to its own thing.

@getify I think generating external documentation should be possible but, at this moment, I'm mainly thinking of ways to support and enhance TypL with it so TypL has even more goodies to attract developers.
With that extra meta information about a function, could TypL augment its runtime error messaging to be more specific?
Given:
function getCommaSeparatedNumberStringPair (aBool = bool, aNumber = number, aString = string) {
  return aBool ? string`${aNumber}, ${aString}` : string`No bueno.`
}
documentation (getCommaSeparatedNumberStringPair, {
  description: 'This function joins a number and string together to create a new string.',
  parameters: {
    aBool: 'some description of aBool',
    aNumber: 'some description of aNumber',
    aString: 'some description of aString',
  },
  returns: 'aNumber comma separated from aString if aBool is true, otherwise a default message.',
})

Usage somewhere:
getCommaSeparatedNumberStringPair(anArbitraryBool, anArbitraryString)

TypL Error:
  Invalid types for getCommaSeparatedNumberStringPair.
  Received Arguments:
     1. VALID: a value of type boolean
     2. INVALID: a value of type string
     3. INVALID: No argument present
  Function Parameters:
     1. aBool: boolean - some description of aBool
     2. aNumber: number - some description of aNumber
     3. aString: string - some description of aString
  Suggestion:
    Fix types on Function Parameters #2 and #3.

Function Parameters above is where we see the mixture of TypL's type information and the user-generated documentation. And documentation could be configurable to spit out more or less information. A developer could configure the output to include description and returns, unlike what you see above.
And of course, the other big use case is IDE auto-completion, tooltips, etc.

This is an interesting and intriguing idea. I think we definitely need another issue thread to discuss/track it.
My inclination would be to try to invent a way for that documentation (stuff used to control error messages) inlined with the type annotations in some way. Maybe that wouldn't work, dunno. But the overall idea I like, just need to consider possible approaches carefully.

@getify Awesome! I'll create a ticket for this idea sometime this evening 👍
@jzombie Thanks for your input too! 💪

@kee-oth  Yep, I've been tracking this repo off and on for a couple of years now and interested to see where it goes.
@getify You do amazing work for the community.  Thanks for everything you share.


Code not launching in Extension Development Host mode

Issue Type: Bug
Steps to reproduce:

Generate a new extension using Yeoman by following the instructions here.
Open the newly generated project in Code
Press F5 to start the Extension Development Host instance of Code.

Expected results:

A new instance of Code with my Hello World extension loaded

Actual results

A generic electron window with electron/chromium/node version information and instructions on how to run electron apps.

Does the problem occurs with all extensions disabled ?
Yes
VS Code version: Code - OSS 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-29T01:21:42.419Z)
OS version: Linux x64 4.19.4-arch1-1-ARCH

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (4 x 960)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: unavailable_softwarevideo_encode: unavailable_softwarewebgl: enabledwebgl2: enabled

Load (avg)
1, 1, 1

Memory (System)
7.72GB (4.70GB free)

Process Argv
.

 Is it stable, insiders or running from sources (OSS) ?

I think we do not support launching an extension from OSS build.
@bpasero / @weinand  Please correct me if I am wrong.

Of course we do support launching an extension from OSS build.
And we have special code to prevent the problem described above from happening.

@Yumasi does this problem reproduce if you run VS Code without extensions?

@weinand yes, I'm still facing this issue if I run vscode with --disable-extensions.


Add Contributor's List in Readme.

There are many contributors to an open source project.
It is always a good idea to give our contributors a shout-out.  :tada:
We would be happy to include a list of contributors who have been contributing to this project. :gift_heart:
The task is to add a list of contributors (in a clean, concise, and attractive way) to the Readme of the project.
Additional context
A simple start can be considered, but
It will be a bonus if the whole process can be automated. :+1: :star:

Hey there, can i participate in this too? i can fully automate this process.

hey @donheshanthaka I am already on it! Hope you would find another! :)


Changed WorldMapWalker to walk when not moving, instead of idle

Changed WorldMapWalker to walk when not moving, instead of idle

remove the actions stuff please

remove the actions stuff please

I'm not sure how lol 😂

Use git rm [file] on the files you added. You did git add on the files or intellij is configured to automatically add new files. Then do a commit and push. The latest commit here should show the deletion (untracking) of the files. It doesn't delete your files locally.

It seems like everything is ready for merging, you took care of the workflow directory files being added.


[BUG] Any player can open shop chests

Description
Any player can open any shop chest.  You might have had someone ask you about this problem on your discord.  With debug enabled, I see this message Storage Block PerData: null which I think means the plugin doesn't think it's a shop chest despite having the proper sign and json file.  Breaking the sign, and re-creating the shop fixes the problem.  The server owner told me that the shops were created with an older version of the plugin.

Please state the server and plugin version, as well as the older plugin version from which the server owner presumably upgraded.

Server was probably Paper 322.
Plugin version 2.2.5-STABLE
As for previous version, I do not know.  I only help the owners with their server when they have problems.  I can probably get you one of the problematic json files, if that would help.

Can not duplicate, closing.