How to integrate with @sanity/image-url?

Hey!
I was hoping I could use the createClient to configure the client for the @sanity/image-url package, but it doesn't work 🤔
What the best/cleanest of using @sanity/image-url with the Nuxt sanity-module?
// Nuxt plugin
import imageUrlBuilder from '@sanity/image-url'
import { createClient } from '@nuxtjs/sanity'

const configSanity = {
  projectId: 'tufjlt9c',
  dataset: 'production',
}

const client = createClient(configSanity)
const builder = imageUrlBuilder(client)

function urlFor(source) {
  return builder.image(source)
}

export default (context, inject) => {
  inject('urlFor', urlFor)
}

<img :src="$urlFor(movie.poster)" :alt="movie.title + ' poster'" />

Try this:
// Nuxt plugin
import imageUrlBuilder from '@sanity/image-url'

const configSanity = {
  projectId: 'tufjlt9c',
  dataset: 'production',
}

export default ({ $sanity }, inject) => {
  const builder = imageUrlBuilder($sanity.client)

  function urlFor(source) {
    return builder.image(source)
  }

  inject('urlFor', urlFor)
}

thanks for the quick response 😃
but still no luck: https://github.com/mornir/movies-web/blob/master/plugins/image-builder.js
When logging, I can see that the client was initialized.
(I'd like to use the crop & hotspot feature of the studio, which I assume SanityImage can't render)

I'm using the minimal client (piconsanity). I tried using @sanity/client, but I get the following error, although I have it installed:

@mornir That's a bug - give me a sec.

@mornir Try with v0.3.7 - should correctly detect @sanity/client

Nice! The warning is gone, but now I get this error:
 ERROR   /

server.js:612
      useOfficialClient = !!(/*require.resolve*/)(33);
                                                ^

SyntaxError: Unexpected token ')'
    at new Script (vm.js:88:7)
    at C:\projects\movies-web\node_modules\vue-server-renderer\build.prod.js:1:77446
    at o (C:\projects\movies-web\node_modules\vue-server-renderer\build.prod.js:1:77509)
    at C:\projects\movies-web\node_modules\vue-server-renderer\build.prod.js:1:78172
    at new Promise (<anonymous>)
    at C:\projects\movies-web\node_modules\vue-server-renderer\build.prod.js:1:78080
    at Object.renderToString (C:\projects\movies-web\node_modules\vue-server-renderer\build.prod.js:1:81615)
    at SSRRenderer.render (C:\projects\movies-web\node_modules\@nuxt\vue-renderer\dist\vue-renderer.js:3822:38)

The error occurs when setting the client to minimal.

Apologies for that. Let's try v0.3.8.

@danielroe Thanks for the quick fix!
!!((process.client || process.server) ? require.resolveWeak('@sanity/client') : require('@sanity/client'))😵😄
Back to my original question:
Initializing the image builder with context.$sanity works when using minimal: false, but not with minimal: true, which is odd, because this does work:
import sanity from 'picosanity'
import imageUrlBuilder from '@sanity/image-url'

const client = sanity({
  projectId: 'tufjlt9c',
  dataset: 'production',
})

const builder = imageUrlBuilder(client)
const urlFor = (source) => builder.image(source).auto('format')

export default (context, inject) => {
  inject('urlFor', urlFor)
}

@mornir I'll need to look into the image URL builder. I think I recall it is only requesting the client to get the configuration, which it's assuming is available - as it doesn't need to perform any fetches.

Answer is don't pass in the current, just the config, which image builder supports as well. Or we can modify the minimal client to return its config via the clientConfig

Oh I see 😯
yeah, the following plugin would be neat. Are there any downsides in exposing the client config like this?
import imageUrlBuilder from '@sanity/image-url'
export default ({ $sanity }, inject) => {
  const builder = imageUrlBuilder($sanity) // image-url will automatically look for the clientConfig key, right?
  function urlFor(source) {
    return builder.image(source)
  }
  inject('urlFor', urlFor)
}

Now I'm importing the Sanity config from the Nuxt config:
import imageUrlBuilder from '@sanity/image-url'
import config from '../nuxt.config.js'

export default (context, inject) => {
  const builder = imageUrlBuilder(config.sanity)
  function urlFor(source) {
    return builder.image(source)
  }
  inject('urlFor', urlFor)
}

I had to explicitly set dataset to production for it to work (although it's the default value).
Now that I think about it, the best would be that the nuxt-sanity plugin provides the urlFor image helper globally.

I propose exposing the config like so:
import imageUrlBuilder from '@sanity/image-url'
export default ({ $sanity }, inject) => {
  const builder = imageUrlBuilder($sanity.config)

  function urlFor(source) {
    return builder.image(source)
  }

  inject('urlFor', urlFor)
}

I'm reluctant to embed @sanity/image-url as it will increase the bundle size by 7Kb (parsed JS) when not everyone will use it.

Good for me 👍

... now usable in v0.3.9

Thanks!


Bluetooth: Rework the HCI header set

Bluetooth: Rework the HCI header set

In order to have clean, self-contained HCI headers that do not have any
dependencies towards the Host or any other part of the system (except
types), reorganize the headers in the following way:

- Split out the macros and structs from hci.h to a new hci_types.h
- Merge the existing hci_err.h into the new hci_types.h

Fixes #58214.

@carlescufi  I did some more clean up in Controller in a new commit in this PR: 7af43d235ff66cd0bde8a7d7deb7a93994865e8f

Controller does continue to include <zephyr/bluetooth/conn.h  and <zephyr/bluetooth/iso.h (in c source files, not in include headers) for connection role definitions and ISO packing (sequential or interleaved), respectively. These exceptions in the Controller C source file should be addressed outside the scope of this PR. Otherwise, the changes in this PR looks good to me.


drawing performance optimization help

I use pixi.js to draw some lines.when there are many lines, render speed becomes slow, can anyone help me to optimize performance of it? thanks for help.
I gave up using Graphic API to draw because it could not set the lineCap and lineJoin style of lines.
I made a pen here :
https://codepen.io/superliwei/pen/XyydVy

http://www.html5gamedevs.com/topic/41582-drawing-performance-optimization-help/
Lets continue it here ;)


Hide nifty wallet unless the user has it enabled

Title is the primary update, however, what started as a very easy fix revealed a security issue with a dependency used in the testing framework. Fixing this error then illuminated issues in our tests with a missing typescript property as well as a missing polyfills. Fixing these then had issues with the install.
I have changed the npm audit command to only run on production dependencies and reverted the package updates.
Resolves #278

👌🏻 Great!


make user ssh key not mandatory when creating user-param document

The problem is on in the ssh key.
Instead, after new user creation via OIDC, user-param resource cimi-side with the user General parameters is not created.  The General parameters that are seen on the old UI in the Profile are the default ones and available only in memory until they are edited and saved.


chore: set allowPrivilegeEscalation to false

Signed-off-by: Nilekh Chaudhari<EMAIL_ADDRESS>
Reason for Change:

This PR adds following additional security context.

allowPrivilegeEscalation: false

Requirements

[x] squashed commits
[x] included documentation
[ ] added unit tests and e2e tests (if applicable).

Issue Fixed:

fixes #537
Does this change contain code from or inspired by another project?

[ ] Yes
[x] No

If "Yes," did you notify that project's maintainers and provide attribution?
Special Notes for Reviewers:

/azp run pr-e2e-azure

Codecov Report

Merging #549 (707706e) into master (b271625) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #549   +/-   ##
=======================================
  Coverage   61.49%   61.49%
=======================================
  Files           7        7
  Lines         535      535
=======================================
  Hits          329      329
  Misses        172      172
  Partials       34       34

/azp run pr-e2e-azure


Fail e2e tests if no test matched

What this PR does / why we need it:
We had a problem with periodic jobs that wouldn't fail when we mess with test names and forget to update periodics.
Which issue(s) this PR fixes:

Fixes #
What type of PR is this?
/kind bug
Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

NONE

Documentation:

NONE

/retest


Nuxt Icons unable to resolve the components/global icons when components prefix has been disabled

I am using nuxt-icon ^0.4.2 and i have auto imports enabled in which the icons are working properly like this:
<Icon name="LeafIcon" />   // LeafIcon is icon component inside components/global
But when I try to remove/disable suffix for the components folder for auto imports like this in my nuxt.config.ts it is not working (ie. above global icon not working ):
export default defineNuxtConfig({
   components: [
      {
         path: '~/components',
         pathPrefix: false
      }
   ]
)}

I also tried to enable prefix for components/global folder as that might be the issue causing the global icon not being imported.
export default defineNuxtConfig({
   components: [
      {
         path: '~/components',
         pathPrefix: false
      },
      {
         path: '~/components/global',
         pathPrefix: true
      }
   ]
)}

Even after doing this I was not able to solve this issue. Is there anything wrong that I have been doing or is it just the issue of nuxt? I just wanted to remove the prefix for components folder as working with larger components nested inside components folder like components/page/search/TopBanner.vue would make things complicated as we have to write <PageSearchTopBanner /> for auto importing that component. Please help on this as I am not able to use the components/global icons for my nuxt-icon.

Could you check in the Nuxt Devtools, in the components tabs the names of your components?

Component:

I am talking about the Nuxt Devtools

I can see this <Icon /> being used in the nuxt devtools. nuxt icon is working but just for the custom icon components inside components/global is not working.
In the user components in nuxt devtools, I can see the name of my custom component inside components/global:

This is the nuxt icon being used here:

Then ArrowIcon should work.
You can see a working playground on https://stackblitz.com/edit/nuxt-icon-playground?file=app.vue

Nope, it's not working as something when that component: [] is added to the nuxt.config.ts is causing this issue.
You can check this as I have replicated what I wanted and added some comments there. This should be expected to work but it's not working. I tried workaround like making pathPrefix true for components/global in the nuxt config which also seems to not work.
https://stackblitz.com/edit/nuxt-icon-playground-1kycsn?file=app.vue

Could you try adding the global: true ?

Close as this should be no longer relevant with Nuxt Icon v1


Git install failing

Hi! I tried to follow your README directions but am getting an error after install in Colab when trying to import lap:
pip install git+https://github.com/rathaROG/lapx.git

import lap

@rathaROG also if I try to import laxpx I get no module, so I'm assuming the lap usage is supposed to stay the same, i.e. import lap following install of this repo?

Hi @glenn-jocher, I'm sorry for the bug.  For now, please use v0.5.1 since I kept the same setup procedure as in the original Tomas Kazmar's gatagat/lap.
pip install<EMAIL_ADDRESS>
I shouldn't have published the v0.5.2 or put it in main branch as it's still under experiment... anyway I'm fixing it soon... maybe I'll switch to use something like cmdclass instead of ext_modules:
class CustomCythonizeCommand(distutils.cmd.Command):
  description = 'Cythonize the _lapjb_src'
  def run(self):
    cythoninzer_py = os.path.join(os.getcwd(), "cythonizer.py")
    print(cythoninzer_py)
    command = [sys.executable, cythoninzer_py, "build_ext", "--inplace"]
    subprocess.check_call(command)

Hi @glenn-jocher, fixed! https://github.com/rathaROG/lapx/commit/951fcb15775a009570bdae225243b32406577604
PyPi will be soon available as well.
I hope you continue using it.. :)
I like your Ultralytics by the way.

@rathaROG oh thanks buddy. We've had users with difficulty installing lap from pypi, so I recently updated to install from the lap repo (after first installing cython).
We use lap for YOLOv8 tracking, i.e. see https://docs.ultralytics.com/modes/track
If you deploy a PyPI package that would be awesome! lap is super important for our tracking but unfortunately it's not maintained anymore, so I have some hopes here :)

My current workflow is here. lap is not a required dependency, it's only installed when someone first tries to use a tracker (many users may never track).
https://github.com/ultralytics/ultralytics/blob/4e08e122564a7a09693bb8df25a93c5f09db5010/ultralytics/tracker/utils/matching.py#L9-L19

@rathaROG oh thanks buddy. We've had users with difficulty installing lap from pypi, so I recently updated to install from the lap repo (after first installing cython).
We use lap for YOLOv8 tracking, i.e. see https://docs.ultralytics.com/modes/track
If you deploy a PyPI package that would be awesome! lap is super important for our tracking but unfortunately it's not maintained anymore, so I have some hopes here :)

lapx is now live on PyPI. Please have a try!
https://pypi.org/project/lapx/


Hardcoded Secret Key

The SECRET_KEY is hardcoded in the code (SECRET_KEY = "cf4d68b60166f3e77fa11213797e2ee9ace4e813eead3fdbc522079ecee9beb2"), which poses a serious security risk. If the source code is publicly available, anyone can access this secret key and use it to generate or decode JWT tokens.
Store the SECRET_KEY as an environment variable.

Within GitHub, secret key is stored as an environment variable should we need to run the code in GitHub Actions.

This issue has been addressed in the latest commit. The SECRET_KEY is now retrieved from an environment variable, eliminating the security risk of a hardcoded key in the source code. The PR has been updated to reflect these changes. Unless there are any further concerns, this issue can be considered resolved.


Remove bootstrap layout in favour of a Front Matter toggle

This pull request removes a Bootstrap layout and instead allows users to opt-in for it by specifying
bootstrap: true

in page's/post's Front Matter.
Implements suggestion from #94

All good! Thanks ;)


Internalizer with read only property

Internalizer with read only property doesn't work - it fails with "Property is not writable". Here is test case:
using System;

public class ClassWithReadOnlyProperty
{
    private ComplexProperty _property = new ComplexProperty {SomeString = "Initial"};

    public ComplexProperty Property
    {
        get { return _property; }
    }
}

public class ComplexProperty
{
    public string SomeString { get; set; }
}

public static class Program {
    public static void Main (string[] args) {
        var instance = new ClassWithReadOnlyProperty
        {
            Property = { SomeString = "Modified" }
        };

        Console.WriteLine(instance.Property.SomeString);
    }
}

I'll look on this issue later today.

Works, test to be added?


add mode example to custom aggregation

There's an example of a mode custom aggregation on SO https://stackoverflow.com/a/46082075/6046019
Do you think it would be of benefit to add it the docs as another example at the bottom of https://docs.dask.org/en/latest/dataframe-groupby.html#aggregate?

That could be added, with a caveat about how it breaks ties when there are
multiple modes.
On Tue, Jun 16, 2020 at 10:53 PM Ray Bell<EMAIL_ADDRESS>wrote:

There's an example of a mode custom aggregation on SO
https://stackoverflow.com/a/46082075/6046019
Do you think it would be of benefit to add it the docs as another example
at the bottom of
https://docs.dask.org/en/latest/dataframe-groupby.html#aggregate?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/6329, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAOISEFWW356OEVNUMUR3RXA45FANCNFSM4OAGNRVQ
.

That could be added, with a caveat about how it breaks ties when there are multiple modes.

Interesting. I see that in pandas as well.
Note: the code below is WIP.
import pandas as pd
import pandas._testing as tm
import dask.dataframe as dd

d = {'col1': [1, 1, 1, 1, 1], 'col2': [5, 6, 6, 6, 7]} # Works
#d = {'col1': [1, 1, 1, 1, 1], 'col2': [5, 5, 6, 6, 7]} # Does not work
df = pd.DataFrame(data=d)
expected = df.groupby('col1').agg({'col2':pd.Series.mode})

ddf = dd.from_pandas(df, npartitions=2)

mode = dd.Aggregation(
    name="mode",
    chunk=lambda s: s.value_counts(),
    agg=lambda s0: s0._selected_obj.groupby(
        level=list(range(s0._selected_obj.index.nlevels))
    ).sum(),
    finalize=lambda s1: s1.groupby(level=list(range(s1.index.nlevels - 1))).apply(
        lambda x: x.reset_index(
            level=list(range(x.index.nlevels - 1)), drop=True
        ).argmax()
    ),
)

def chunk(s):
    return s.value_counts()

def agg(s):
    return s.apply(lambda s: s.groupby(level=-1).sum())

def finalize(s):
    level = list(range(s.index.nlevels - 1))
    return (
        s.groupby(level=level)
        .apply(lambda s: s.reset_index(level=level, drop=True).argmax())
    )

mode = dd.Aggregation('mode', chunk, agg, finalize)

actual = ddf.groupby('col1').agg({'col2':mode}).compute()

@raybellwaves  Are you still interested in adding the example above or some version of it? I'm noticing there are no PR's linked to this issue.

For what it's worth: I could not get the above code to work, and spent a bit of time debugging it before realizing that .argmax in the finalize function is getting the integer position of the most common value, not the value itself; replacing with .idxmax works.

Slightly modified code that also allows for multiple values of the mode (as seen on StackOverflow):

from pandas import DataFrame, Series, NA
from dask.dataframe import from_pandas, Aggregation

data = DataFrame(
    {
        "status": [
            "pending",
            "pending",
            "pending",
            "canceled",
            "canceled",
            "canceled",
            "confirmed",
            "confirmed",
            "confirmed",
        ],
        "clientId": ["A", "B", "C", "A", "D", "C", "A", "B", "C"],
        "partner": ["A", NA, "C", "A", NA, "C", "A", NA, "C"],
        "product": [
            "afiliates",
            "pre-paid",
            "giftcard",
            "afiliates",
            "pre-paid",
            "giftcard",
            "afiliates",
            "pre-paid",
            "giftcard",
        ],
        "brand": [
            "brand_4",
            "brand_2",
            "brand_3",
            "brand_1",
            "brand_2",
            "brand_3",
            "brand_1",
            "brand_3",
            "brand_3",
        ],
        "gmv": [100, 100, 100, 100, 100, 100, 100, 100, 100],
    }
)

data = data.astype(
    {
        "partner": "category",
        "status": "category",
        "product": "category",
        "brand": "category",
    }
)
mode_pandas = data.groupby(["clientId", "product"], observed=True).agg(
    {"brand": Series.mode}
)

df = from_pandas(data, npartitions=1)

def chunk(s):
    return s.value_counts()

def agg(s0):
    _intermediate = s0._selected_obj.groupby(level=s0._selected_obj.index.names).sum()
    _intermediate = _intermediate[_intermediate > 0]
    return _intermediate

def finalize(s):
    level = list(range(s.index.nlevels - 1))
    return s.groupby(level=level, group_keys=False).apply(lambda s: s[s == s.max()])

mode = Aggregation(
    name="mode",
    chunk=chunk,
    agg=agg,
    finalize=finalize,
)

mode_dask = df.groupby(["clientId", "product"], observed=True, dropna=True).aggregate(
    {"brand": mode}
).compute()

print(mode_pandas)
print(mode_dask)

@SultanOrazbayev: Thanks for providing this example! Would you be interested in contributing a PR that adds the example or a simplified version to the Dask documentation?


DbSet.WithSpecification together with ISpecification<T, TDestination> throws SelectorNotFoundException

I have the following specifications defined:
    public class BlogPostByTitleSpec : Specification<Post>
    {
        public BlogPostByTitleSpec(string title)
        {
            Query.Where(c => c.Title.Contains(title));
        }
    }

    public class BlogPostByTitleDtoSpec : Specification<Post, PostDto>
    {
        public BlogPostByTitleDtoSpec(string title)
        {
            Query.Where(c => c.Title.Contains(title));
        }
    }

I use them like so (working example):
var blogPostByTitleSpec = new BlogPostByTitleSpec("Hello");
var postsByTitle = await db.Posts.WithSpecification(blogPostByTitleSpec).ToListAsync();

And like this (throws exception):
var blogPostByTitleDtoSpec = new BlogPostByTitleDtoSpec("Hello");
var postsDtoByTitle = await db.Posts.WithSpecification(blogPostByTitleDtoSpec).ToListAsync();

The exception thrown is:
Ardalis.Specification.SelectorNotFoundException: 'The specification must have a selector transform defined. Ensure either Select() or SelectMany() is used in the specification!'

I thought it was related somehow to the type change/mapping defined in the specification, so I've tried fiddeling with both Mapster and Automapper, for instance like this:
var postsDtoByTitle = await db.Posts.WithSpecification(blogPostByTitleDtoSpec).ProjectToType<PostDto>().ToListAsync();

But that gives the same error.
The only way I have found around this problem is to define a Select directly in the specification, like this:
public BlogPostByTitleDtoSpec(string title)
        {
            Query
                .Select(x => new PostDto()
                {
                    Id = x.PostId,
                    BlogId = x.BlogId,
                    Title = x.Title,
                    Content = x.Content
                })
                .Where(c => c.Title.Contains(title));
        }

Can anyone explain what I'm doing wrong?

Hi @tomaforn,
There are two types of base specification classes, Specification<T> and Specification<T, TResult>. If you are using the latter, then the specification must contain the Select expression. That's by design. That's precisely what the error message says. We're not doing any automatic mapping if that's what you expected.
So, the usage will be as follows:

var posts = await db.Posts.WithSpecification(BlogPostByTitleSpec ).ToListAsync(); - Get post entities.
var postsDtoByTitle = await db.Posts.WithSpecification(BlogPostByTitleDtoSpec ).ToListAsync(); - Get dtos directly. In this case the spec must contain the projection expression (the last example in your post).
var postsDtoByTitle = await db.Posts.WithSpecification(BlogPostByTitleSpec).ProjectToType<PostDto>().ToListAsync(); - Using AutoMapper for projection. In this case, use BlogPostByTitleSpec, not the BlogPostByTitleDtoSpec spec.  It means you're just building the IQueruable<Post> to a given point, and then passing it to Automapper to add the select expression.

Let me know if this helps to clarify the confusion.

Hi @fiseni,
Ah, so that explains why it wasn't working, thanks!
I was writing an extension method for IQueryable when i ran into the issue, something like this:
public static async Task<PaginationResponse<TDestination>> ProjectToPaginatedListAsync<T, TDestination>(
        this IQueryable<T> query, ISpecification<T, TDestination> spec, int pageNumber, int pageSize, CancellationToken cancellationToken = default)
        where T : class
        where TDestination : class
    {
        int count = await query.WithSpecification(spec).CountAsync(cancellationToken);
        if (count > 0)
        {
            var list = await query.WithSpecification(spec).ProjectToType<TDestination>().ToListAsync(cancellationToken);
            return new PaginationResponse<TDestination>(list, count, pageNumber, pageSize);
        }
        return new PaginationResponse<TDestination>(new List<TDestination>(), 0, 0, 0);
    }

I was hoping I could require the ISpecification<T, TDestination> base as input to deduce the target type and handle the projection inside, but from your answer I'm not sure that's possible?
I guess I could change it into something like this instead:
public static async Task<PaginationResponse<TDestination>> ProjectToPaginatedListAsync<T, TDestination>(
        this IQueryable<T> query, ISpecification<T> spec, int pageNumber, int pageSize, CancellationToken cancellationToken = default)
        where T : class
        where TDestination : class
    {
        int count = await query.WithSpecification(spec).CountAsync(cancellationToken);
        if (count > 0)
        {
            var list = await query.WithSpecification(spec).ProjectToType<TDestination>().ToListAsync(cancellationToken);
            return new PaginationResponse<TDestination>(list, count, pageNumber, pageSize);
        }
        return new PaginationResponse<TDestination>(new List<TDestination>(), 0, 0, 0);
    }

But it would be nice to be able to do
var pagedAndMappedResultByTitle = await db.Posts.ProjectToPaginatedListAsync(blogPostByTitleDtoSpec, 1, 5, CancellationToken.None);

instead of
var pagedAndMappedResultByTitle = await db.Posts.ProjectToPaginatedListAsync<Post, PostDto>(blogPostByTitleSpec, 1, 5, CancellationToken.None);

Do you know if it's possible to extend like in the first example, without having to manually map the types in the specification?

I had totally missed those samples, they look to be exactly what I was looking for as you said.
Thanks for pointing me there!


Bug TypeError: Cannot read property 'prototype' of undefined

i got error when i use this lib on expo sdk 49
Error
TypeError: Cannot read property 'prototype' of undefined. Also thanks for great lib

It's because that version of Expo uses react-native-reanimated-3. Looks like this library isn't compatible


[BugFix][Habana-main] Update Dockerfile.hpu to work with v0.6.2 updated setup.py

Recent test with 'Dockerfile.hpu' failed due to v0.6.2 setup.py update
FIX with this issue
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

For v0.6.2 setup.py

It will use "setuptools-scm" to get package version.
fetched version should not contain '-gaudi' inside version_id

Verify this dockerfile.hpu with comdline as below
git clone https://github.com/HabanaAI/vllm-fork.git
cd ./vllm-fork; git checkout habana_main; git tag v0.6.2.post1;
docker build -f Dockerfile.hpu -t opea/vllm:hpu --shm-size=128g . --build-arg https_proxy=$https_proxy --build-arg http_proxy=$http_proxy

Hi, @madamczykhabana, may you take a look of this PR, I tested Dockerfile.hpu after rebasing to v0.6.2, and noticed some new feature in vllm-upstream may break pip installation.
This PR is my quick fix. Thanks


Custom fonts render with glitches on certain Windows devices

Summary

Issue: Text with custom fonts appear with artifacts/glitches on certain Windows machines.
Phaser version(s): Phaser-CE v2.20.0
Live example:

Phaser-CE: https://jsfiddle.net/Akurn/u3xb4rs2/ (the only one that shows the font glitch)
Phaser 3: https://jsfiddle.net/Akurn/58wbe6n7/
PixiJS 3: https://jsfiddle.net/Akurn/13u602wb/
Vanilla JS: https://jsfiddle.net/Akurn/2evyskft/
(I need to do a test on PixiJS v2 in case its also reproducible)

What steps produce the bug:

View the JSFiddle on affected machines in the Chrome browser
So far we've replicated on Dell i7 laptops with Intel Xe integrated graphics chips running either Windows 10 or 11
Text between 10-29 px without a Stroke, seem to be affected more

What should happen: Text should render cleanly
What happens instead: Text renders with random chunks missing from the fill
Screenshot:

Description
Hi all, we've been experiencing this strange text glitch when using custom fonts in Phaser-CE on some Windows machines (it's similar to these posted Chrome issues, caused by hardware rendering. And is also addressed when hardware rendering is turned off).
Even though this does appear to be a Chrome/Windows issue, the reason I'm posting it here is that I've tested this with various other Canvas 2D frameworks, and they all seem to circumvent the issue, as I only see it in Phaser-CE (yet to test PixiJS v2, but v3 is fine). Links to each version are listed above.
I plan to further investigate this issue myself when I get more time, but thought to post it here in case others have also experienced the issue, or have ideas of what it could be. Or maybe we need to replicate what other frameworks do, and patch Phaser-CE to address it.
The glitch only appears in Chrome on some Windows machines (i7 laptops with integrated Intel Xe graphics). Our company supplies these to some non-dev employees, and most or all are seeing this glitch. It does not appear on MacOS or Desktop Windows (with dedicated graphics chips). On the affected machines it doesn't matter the display drivers versions, Windows updates or Windows versions 10 or 11, all show the glitch. I suspect it's related to type of hardware, since our tested Desktops don't reproduce the issue.
The bug has been seen for over a year (since 2022). Haven't tested with other Phaser-CE or Pixi versions other than listed above.
More Symptoms

The location of the missing chunks is inconsistent, refreshing or reloading the text object, can change the glitch locations, or even not show it
Doesn't matter on the particular font (tested over 20 different custom fonts, both Google Fonts and custom loaded ttf)
Larger text sizes (above 30px) don't seem to show it
In certain conditions, the first text object doesn't have the glitch, but additional text objects can
Changing font sizes also removes the glitch but only if the next font size is drastically different (within a few pixels, 1-4px difference, they can still be visible)
Adding a text stroke (even very tiny like 0.0001) or rendering the text without fill, also avoids the issue
The text possibly also needs word wrapping and a new line char (\n)

Current Workarounds

Turning Off Hardware Rendering in Chrome prevents the issue: https://support.google.com/chrome/thread/2331445/chrome-displaying-font-problem?hl=en
Calling text.updateText() after instantiation, also seems to prevent the glitches (our current workaround)

Suspected issues
It could be some memory issue related to BaseTexture in updateTexture method?

I plan to investigate this more, but thought to post it here first to gather some helpful clues or additional things to check or test

Someone reported a similar issue in Phaser 3.

We've just had reports of the same thing happening, thanks for reporting

The Text Game Object is literally just a hidden canvas that uses fillText to draw the text to it. The Canvas API does all of the text rendering, strokes, etc. The canvas is then turned into a WebGL texture and uploaded to the GPU.
If disabling hardware rendering fixes it, then clearly something is very wrong in that combination of Chrome + GPU + Windows. The fact that resizing the text to a much larger size fixes it is curious. Doing that would cause it to resize the canvas it was using, re-draw the text, and re-upload it to the GPU. Perhaps this is triggering a certain size threshold (next power of two up, perhaps?) on the GPU?
Also, I wonder if mipmaps may cause this. I honestly can't remember if they're supported in CE, but if they are, I would try disabling them.
We definitely can't fix the root cause of the issue (i.e. whatever causes Chrome to nuke parts of the font), but maybe there is a combination of sizes, or a certain texture size/ratio that prevents it from occurring in the first place. If you were to run WebGLSpector on one of the 'broken' machines, you could profile a frame and inspect all of the textures on the GPU. I fully expect you to see the glitch in there, but you'd also get to inspect the rest of the texture properties, too. I still reckon this is related to the base canvas size that the Text object creates initially (which is driven by the text content)

You've just made me realise I've overlooked the type of renderer in my tests. Currently I've only seen the issue via the Canvas renderer, but I now realise the tests in Phaser 3 and Pixi are likely using WebGL. So I'll need to do some more tests with WebGL vs Canvas2D once I get access to the broken machines again.
Thanks for all the replies and insight, already very helpful ❤

Was there any update on this? Having the same issue.

Hi @DennisEmberex, unfortunately I haven't been able to get back to this to add more tests, but it is still on my radar as we are needing to do prod hacks to circumvent the issue. Hopefully I'll have a chance in the next couple of weeks.
In the meantime, it would be helpful to know if you have any example links where the issue is occurring, as well as any browser and hardware specifications. Thanks!

I was able to update to previous tests.
For the Phaser 3.7 and Pixi 3 tests, I've enforced the Canvas rendered:

Phaser 3: https://jsfiddle.net/Akurn/58wbe6n7/6/
PixiJS 3: https://jsfiddle.net/Akurn/13u602wb/13/
And both don't have issues.

I've also made another Phaser-CE test to try WebGL:

Phaser-CE: https://jsfiddle.net/Akurn/ygje5faq/2/
And it contains the same Font glitch.

We've also had some more recent issues where my previous hack (calling updateText()), doesn't do anything if setText has been used while the text object is hidden. This might be worth investigating more.
In the meantime, I'll have a look more at PhotonStorm's suggestions and try run WebGLSpector (I found a couple, WebGL-Inspector and Spector.js - not sure which was the correct one to try, but will give them a go).
It might also be worth spitting out the hidden canvas texture of the text, into the DOM. Maybe it will show it broken too 🤷
Will touch base again once I've done more testing


Replace arrays of Parquets with arrays of ParquetIDs.

This should be done only after CSV serialization has been achieved, since this relies on AllParquets as a palette of parquet definitions.

Done as of PR #12.


Auto hp not what rolled

When a token is placed out - the roll shows the result, but the hp result on the token is different. It IS still randomizing on the tokens, but not to the amount shown in the roll.
Core 0.6.2
D&D5e 0.92
Token-Mold 2.6.1

Disregard! I realized that there was a conflict with CUB also rolling hp.
CUB was rolling first (showing the dice in the chat, and then TM rolling actually putting hp that was on the token).


About the network model and codes

Hello, your work is very amazing, but when will you release the network structure and training code?
Thanks！

Hi @song201216 , thank you for your interest in this project. We plan to release the online demo soon for inference. Since the model was developed during my internship, I am still at the stage to request permission for releasing the code.

I hope you're successfull in your request to release.
One thing I'm curious about is if you were able to test this with a faces dataset to see how it performs.
Also, how long does training take given the hardware that you had?

I hope you're successfull in your request to release. One thing I'm curious about is if you were able to test this with a faces dataset to see how it performs. Also, how long does training take given the hardware that you had?

Hi, thank you for your interest in our project! We will release the online demo of CM-GAN soon (probably in the next two months) and will most likely release the training code after releasing the online demo. Currently, we only test the model on Places2 but we are working on training an FFHQ model. Our model is trained on A100 GPUs for 1 week (similar to CoModGAN).

How many GPUs were used?

Any news about the pre-trained model? :) Loved the paper, would love to benchmark it.

@roimulia2 I am gradually working towards releasing the model. Currently, the dataset, panoptic annotation, evaluation of CM-GAN, and the on-the-fly mask generation code are released. Will work on the online demo next.

I hope you're successfull in your request to release. One thing I'm curious about is if you were able to test this with a faces dataset to see how it performs. Also, how long does training take given the hardware that you had?

Thank you for raising this and it is a very good point. We are also interested in training a model on FFHQ and will possibly work on it later.

Dear author, hello! I am also interested in the network model of your article, may I ask whether it will be updated on Github after the license is released? I do object detection, would like to quote this article, if convenient, can you send a copy to<EMAIL_ADDRESS>thank you very much!

Thank you for the amazing work and impressive results. I am wondering that when will you release the code? Thanks much.

@htzheng Hello, could you release the training and inference code ?And it seems I cannot open this link[places2_panoptic_annotation]

Since my company is developing products with CM-GAN, they are still deciding when to release the code. Sorry about this...

Hello, I am very interested in what you have published. Can I publish the training code of CM-GAN?

@htzheng I am very interested in the Lama-OT model. Is it possible to release the weight file of this model? Thank you.

你们的工作非常有趣，不过对论文中的有些地方比较困惑，可以方便解答？

你们的工作非常有趣，不过对论文中的有些地方比较困惑，可以方便解答？

看了你们的文章，感觉很有趣，不过有几点不是很清楚，可以方便解答下？

看了你们的文章，感觉很有趣，不过有几点不是很清楚，可以方便解答下？

1 你们的Fout g也是会单独计算loss是？
2 第二decoder是不引入encoder的信息，只拿取第一个decoder的Fine?


question - multiple ports with same service name

Hi,
I'm trying this tool with many complex wsdl files, I have an issue that honestly I don't know if it's a limitation of SoapClient or a bug on generated classes.
I have this wsdl where it was defined a same service name for multiple ports name.
part of wsdl:

generated code in the service class:
/**
 * Method to call the operation originally named service
 * This method has been renamed because it is defined several times but with
 * different signature
 * @uses SoapClientSystemBase::getSoapClient()
 * @uses SoapClientSystemBase::setResult()
 * @uses SoapClientSystemBase::getResult()
 * @uses SoapClientSystemBase::saveLastError()
 * @param \TestClient\Services\System\StructType\PingReq $parameters
 * @return \TestClient\Services\System\StructType\PingRsp|bool
 */
public function service_245c7036753daf3b829e971418dbcd33(\TestClient\Services\System\StructType\PingReq $parameters)
{
    try {
        $this->setResult($this->getSoapClient()->service($parameters));
        return $this->getResult();
    } catch (\SoapFault $soapFault) {
        $this->saveLastError(__METHOD__, $soapFault);
        return false;
    }
}

Every method in the generated file has same code, everything goes on method service and the object $parameters has the correct model / type.
The break point is when the code is executed, the request for each method is always generated using the main service and so the client generate a wrong request using the model for ExternalCacheAccessService.
Any idea, suggests / workaround?

If each port has its own location, you can already call the setLocation method on the Service instance passing through the SOAPAction location before calling the method.
In addition, if the PingReq is inherited from multiple classes, it would mean you have to use one of the inherited classes in order to send the right request content.
Let me know if I'm missing something or if I can help.

Hi,
thanks for your reply...
sorry I did not include the part of the wsdl:
<binding name="SystemInfoBinding" type="tns:SystemInfoPortType">
    <soap:binding style="document"
                  transport="http://schemas.xmlsoap.org/soap/http" />
    <operation name="service">
        <soap:operation soapAction="http://localhost:8080/kestrel/SystemService"/>
        <input>
            <soap:body use="literal" />
        </input>
        <output>
            <soap:body use="literal" />
        </output>
        <fault name="ErrorInfoMsg">
            <soap:fault name="ErrorInfoMsg" use="literal" />
        </fault>
    </operation>
</binding>

Unfortunately the location is always the same for "SystemService".. SoapClient try lookup the service and get always the first match.. so the request is generated always for "tns:ExternalCacheAccessBinding"...
I guess only solution is split the wsdl files into multiple single services... do you have any suggests?

I have an idea but to be sure, I would need some clarification of what you actually send (PHP classes used, sent XML request) and what you actually need to send (XML request).

POST https://endpoint/SystemService HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://localhost:8080/kestrel/SystemService"
Content-Length: 453
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
all requests are as the previous one, endpoint and action are the same for all ports, only the XML request it's different (a model request for each binding).
Splitting the bindings in the single wsdl works well, I wrote a tool for that, It's a limitation of SoapClient that match the first service and port in the wsdl.

So you found a workaround, right?
Did you use the SoapClient inheritance as well? As demonstrated for example in the PackageEws365 package?

Yes I found the workaround splitting the wsdl in multiple wsdl files, so the mapping is one to one. I guess there is no other way.
Yes I'm using the inheritance but unfortunately I can't set extra information into array $options to my SoapClient because the abstract class (AbstractSoapClientBase) is removing keys not present in your wsdl default options.
So I added setter method for injecting extra data, a logger and other stuff.

Great to hear!

Yes I'm using the inheritance but unfortunately I can't set extra information into array $options to my SoapClient because the abstract class (AbstractSoapClientBase) is removing keys not present in your wsdl default options.
So I added setter method for injecting extra data, a logger and other stuff.

Did you try overridding the AbstractSoapClientBase::getDefaultWsdlOptions() method called at https://github.com/WsdlToPhp/PackageBase/blob/develop/src/AbstractSoapClientBase.php#L66 when overridding the SoapClientBase in order to add your own keys?

I missed that method, should help in my case but injection is not bad at all :)
Thanks!


Add session management to the UniFi PHP API

For changing your browser tool, just add is this line:
$_SESSION['unificookie'] = $unifidata->getcookie();
...  directly when $unifidata->login() was successful
Here some pictures for seesing the difference:

[x]
[x]
[x]
[x]

Thank you for the very nice library. I am writing some small HotSpot system with it... when everything is ready, it will also released @ Github...

Thanks for this. I had already implemented something similar in a couple of projects. I haven't spent time checking what the expiry time is for the UniFi cookies though. Have you been able to confirm this?

The time seems to be about 2-5 minutes... but I don't really now it currently. When I have figured out the time @ some time, I will put that info to you ;)
Also, the session thing is nothing special, but maybe some others find it useful, so I created this request.

Cool, thanks for integrating the patch... and also thanks for fixing my comment styling :-)
The UniFi cookie timeout seems to be ~15 minutes.

Thanks for your contribution! Re the comments: there's no good or bad way of doing that, I just have an obsession for consistency:smile:


Abort in "panic_if_*" intrinsics

These three intrinsics should, IMO, abort instead of panic. The main reason we make them panic in rustc is that we want a good backtrace, and doing that from codegen is hard. But causing a panic is easy thanks to libcore having panic support, and std hooking into it.
But in Miri, we can show great backtraces on abort! So, there is no reason to use panics IMO. So I propose that we extend this with an abort message:
https://github.com/rust-lang/miri/blob/704228d0bb65227c82a8b44ab819485912b44007/src/eval.rs#L56
and then cause an abort from the intrinsic.
@elichai that they would look into this.

Might make more sense to name the intrinsics e.g assert_inhabited instead of panic_if_uninhabited.
That would also make aborting instead of panicking in miri less odd-looking.

Had a medical procedure, so sadly I'll only be able to work on it in a few days

No worries, this is not urgent at all. :)

How should I modify these tests to capture the aborts?
Should I make a separate .rs file for each? :/
Should I write the code into a new .rs file, and compile+run it in a new process? something else?
(maybe I can "patch" the abort function so I can catch it? but it might defeat the purpose)

Just remove these things from the catch test. And then add one or two new compile-fail tests instead. See here for an example of another test that aborts.


autoplay and paused props not working in Android

I want to control the video playing status manually,but even I set autopaly={true} and paused={true} it still play automatically.I also had try chenge a playing state in onLoad method,but still not working.

I'm seeing the same issue on Android. As soon as the Video component is rendered it starts playing the video even if rate=0 and paused=true.
It works correctly on IOS.
Any ideas?

Same here. However, if there is something externally that changes the paused property from false to to true, it works. However, it always starts playing, no matter what I do.
Does anyone know the reason for this?

Same here on Android 5.0

@ranjitpandit @Mohamed-Abo-El-Soud  @heartAndRain
Hi, guys , I have found why this happened.This is the PR #625  to fix this problem. the author hasn't merge that. so you can have a look at it and modify the native code. :-)
now we can use pause={true} to make the video stop in the beginning.

Fixed by #1082. In my testing everything is working properly now. Will be released in 3.0. There isn't an autoPlay prop, but if you don't specify a paused prop, it will auto-play.


moving touch buttons into separate file

@pelikhan,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


differentiate rails/vanilla ruby use in README.md

This is a relatively basic change to the README. After seeing another issue that had been closed with regard to the need to call setup, I thought it would be nice to have a section in the docs that shows how to do things outside of the confines of Rails. If you've any stylistic changes you are after, or anything else feel free to let me know :)
:v: :metal:

lgtm! thanks!

No Problem!


WIP: goreleaser: Current docker image broken

ref: #391

help pls pls pls @caarlos0

gorealeaser does not support CGO yet https://goreleaser.com/limitations/cgo/

do you need CGO? if not, you can disable it...

@avelino maybe we missing some flags on build. Could you try add the flag equal here https://github.com/gosidekick/migration/blob/master/.goreleaser.yml ?

@avelino maybe we missing some flags on build to work at alpine image. Could you try add the flag equal here https://github.com/gosidekick/migration/blob/master/.goreleaser.yml ?

very good, I will test
removes the docker image generation from the goreleaser and put it on travis (github release is on the goreleaser)
I'm going to open an issue to work with the migration of the docker image to gorelease - so I can work with more time.

do you need CGO? if not, you can disable it...

@caarlos0 cgo off was giving trouble generating docker image


view resized dimension

When an image is resized in the browser (which happens quite often in responsive websites) I need to check what size the image has been resized down to as well as the original size. This tool does not tell you that. Could we please have that functionality?  There is a browser extension in Chrome: here
that has this functionality, but I've just moved over to using opera (since chrome removed the abilty to go back a page by pressing backspace!)
cheers.

That shouldn't be too hard. I'll look into it.

That extension injects a script into every page all the time to figure out exactly what image you clicked on. (And for some reason it connects to Google Analytics in the background?) Since I'd like to avoid injecting a script until you've actually clicked on something, and because the extension API only gives me the URL of the image you clicked on, I'm just going to search the page for an image with a matching URL. It won't work all the time, but it should work most of the time.

Added in 8b632ac148f3ce24117132f8ccf9109a6b6fb671


Log when signing certs not found in AddSigningCredential, etc.

Can't really achieve this: logging is not yet ready during DI.


Move to builtin hatch functionality+uv

Currently we extra define ruff and pytest but this functionality is already built in hatch.
It currently defaults to require uv which is not a bad idea because this tool is a faster replacement of pip.
So we could transition to pure uv (except the base deps) and use the builtin functionality of hatch instead the own definitions of lint,...
A side-effect could be much faster tests.

if this works, we could apply this to the other dymmond projects

I actually would like to bring UV in as well although I think hatch already uses it but by all means, give it a try

after the refactoring this is true now


Rework Plex connector to avoid use of jQuery that may fail if clobbered by another extension or page script

There's no chance of jQuery being clobbered by another extension or page script because, from Content Script Docs:

the content scripts execute in a special environment called an isolated world. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. It looks to each content script as if there is no other JavaScript executing on the page it is running on. The same is true in reverse: JavaScript running on the page cannot call any functions or access any variables defined by content scripts.

Also version 1 connectors are being phased out so this should be written as V2.  See here for some examples.

@Paszt thanks for the information, I'm a little new to the Chrome extension world. Would it be better for me to rework the Plex connector as a v2 connector?


Style/EndBlock & Lint/EndInMethod are redundant

Both Style/EndBlock & Lint/EndInMethod do the same thing. END block being inside/outside method makes no difference.
Both were added long back in 0.9.0.
Commits don't tell the reasoning either: [1] & [2]
Also the documentation of Lint/EndInMethod suggests END outside method is good which contradicts Style/EndBlock.

Expected behavior
One cop to deal with END blocks.
Actual behavior
Duplicate cops.
Steps to reproduce the problem
NA
RuboCop version
Current master branch.

Great catch! Looking at https://github.com/rubocop-hq/rubocop/commit/8466928ad6793532136ba58324f8a3a21e01cee8 it seems I did this first and then created the other cop based on the remark @whitequark made. I agree it probably doesn't make sense to have two of those.


Duplicate variable declaration [preventScrollOnTouch] in type declaration

Issue description:  Loading inside angular via typescript shows duplicate declaration of
preventScrollOnTouch?: "auto" | "force" | false; line243 and line 260 in tiny-slider.d.ts
Demo link/slider setting:
Tiny-slider version:   2.9.3
Browser name && version:  Edge 11
OS name && version:   Windows 10 x64bit

have the same issue, did you find the fix ?


[7.x] Allow use of invokable controllers in tuple routes

On my new projects I remove the namespace from the RouteServiceProvider and use invokable controllers, so my routes look like Route::get('/hello', HelloController::class). On legacy apps with lots of string notation routes that depend on the default namespace I can't do that. I can use invokable controllers within the default namespace, but if outside the default namespace I have to actually pass '__invoke' as the second parameter in tuple notation like Route::get('/hello', [HelloController::class, '__invoke']). This feels slightly awkward.
This change simply sets the second parameter of the tuple array, if not set, to __invoke. So I would  be able to simply use Route::get('/hello', [HelloController::class]).
Yes, I understand that tuple implies two parameters so this might not be a desirable change. The best counterargument I can make is that it doesn't change any existing behavior and feels slightly less weird to me than adding __invoke as a second parameter.

Thanks for the PR. Could you please add some tests that cover your new code, and also address the tests that are now broken after your changes.

Hi @GrahamCampbell Happy to add tests. The tests were broken before my changes though. They're broken in master right now, and in a way that's a little above my pay grade. Once that's fixed I'll rebase and add some tests.

@GrahamCampbell To clarify, before I made any changes I was getting this when trying to run phpunit:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /Users/ed/Packages/edgrosvenor/framework/src/Illuminate/Database/Grammar.php on line 97

Personally I'm not sure I want to make this change at the moment.

@GrahamCampbell To clarify, before I made any changes I was getting this when trying to run phpunit:

Use ./bin/test.sh to run the tests.

Thanks @GrahamCampbell. Still not working for me, but I'll figure it.


add examples of deployment object

Add 5 examples of deployment object, including:

Create deployment object with client-python API
Create deployment
Update deployment
Roll back deployment
Cascading delete deployment

@mbohlool Please check the PR.  Refer this issue

Ping @mbohlool .I have updated the code style for PEP8. Now, it's ready to be reviewed.

@mbohlool Updated. Plz review.

 I just want to make sure it is working for you before merging it into master.

@DjangoPeng I tried these examples and they gave me syntax errors. That could be because of the new client generation. Can you please take a look at them and make sure that they can be run?

@mbohlool I have fixed the error and tested all examples by myself. Please review and check.

@DjangoPeng The branch is out of date. The new client has some differences (like you need to provide required fields on model creation, etc.). Please rebase to master and run the examples again. An example failure I get:
ValueError: Invalid value for `template`, must not be `None`

@mbohlool Ok, I'll test it today .

I run all examples on Kubernetes 1.7 with client-python 3.0, and I attached the stdout as below. Should I try it on Kubernetes 1.8, or what?
$ python deployment_examples.py
Deployment created. status='{'available_replicas': None,
 'collision_count': None,
 'conditions': None,
 'observed_generation': None,
 'ready_replicas': None,
 'replicas': None,
 'unavailable_replicas': None,
 'updated_replicas': None}'
Deployment updated. status='{'available_replicas': None,
 'collision_count': None,
 'conditions': [{'last_transition_time': datetime.datetime(2017, 10, 13, 1, 30, 1, tzinfo=tzutc()),
                 'last_update_time': datetime.datetime(2017, 10, 13, 1, 30, 1, tzinfo=tzutc()),
                 'message': 'Deployment does not have minimum availability.',
                 'reason': 'MinimumReplicasUnavailable',
                 'status': 'False',
                 'type': 'Available'}],
 'observed_generation': 1,
 'ready_replicas': None,
 'replicas': None,
 'unavailable_replicas': 3,
 'updated_replicas': None}'
Deployment deleted. status='{u'observedGeneration': 1, u'unavailableReplicas': 3, u'conditions': [{u'status': u'False', u'lastUpdateTime': u'2017-10-13T01:30:01Z', u'lastTransitionTime': u'2017-10-13T01:30:01Z', u'reason': u'MinimumReplicasUnavailable', u'message': u'Deployment does not have minimum availability.', u'type': u'Available'}]}'

Use master. You can goto root folder of repo and call python -m examples.deploment_examples. just make sure you rebase to the latest code.

@mbohlool Now, it works on latest master branch. I delete the rollback example because there is a error that I'm debugging and identifying. When I solve it, I'll make a new PR to append the rollback example.

@mbohlool Please review the PR. I think it's ready to be merged.

@DjangoPeng Thanks. Great example.

I have updated the description of the PR. Welcome anyone to append the rollback example of Deployment.


Check Cargo.lock in version control for libraries

Describe the problem you are trying to solve

The official FAQ and various other places strongly suggest (almost mandate) that libraries do not check in Cargo.lock. This serves so that if the library is used as a dependency from another crate, the parent crate should get to decide what particular versions of dependencies to use for itself and all its transitive dependencies, respecting versioning restrictions indicated in the relevant Cargo.toml files.
Describe the solution you'd like

strongly suggest versioning Cargo.lock in version control even for libraries; without this, it is practically impossible to achieve reproducibility of builds, tests and CI pipelines: the same exact version (commit checksum) of a library may compile / pass at some point in time on someone's machine, but spuriously break / fail later on or on some other machine, just because some dependency published a new version on crates.io
add an option to cargo to skip packaging the local Cargo.lock when publishing a library to crates.io (by default it will exclude it for libraries and include it for binaries)

perhaps it is sufficient to manually exclude Cargo.lock from a package until this is implemented

suggest relying on https://dependabot.com/rust/ or manually bumping dependencies in order to detect incompatibilities with new version of dependent crates in an automated way that is tracked under version control and maintains the hermeticity and reproducibility of builds, even for libraries

Notes

### Tasks

Just to be clere a libraries Cargo.lock has no effect on resolution for a project that depends on that library. That is true if the library does not commit its Cargo.lock, and it is true if it commits it but does not include it when publishing, and it is true even if it ends up in the final published artifact. If you commit your Cargo.lock, so your CI is not broken by some new version on crates.io, then the first you will hear about the brokege is from your users.
Whether it is better to have flakey but real test in CI or to have reliable but mocked tests in CI, really depends on the priorities of the library. It is not so different from every other time a project considers using mock objects. Do you call that other microservice, then you will now fast if they broke their api but tests will be flakey, or do you mock it so you have fast reliable test of what that microservice used to respond.

I think it would be fine to add some more details to the documentation. There's a tradeoff, if Cargo.lock is included in source control, you'll likely be testing out-of-date dependencies. That's good for reproducibility as you say, but is bad because you won't quickly catch problems with new dependencies. If you have the CI budget, you can of course test both with Cargo.lock, and with the latest versions (by calling cargo update && cargo test).

Catching problems with new dependencies should not happen when someone is trying to test an unrelated change. Which often results in a new dependency breaking CI, which prevents even other, unrelated changes from going through.
dependabot (or something similar) seems the ideal solution to me, since it guarantees deterministic and hermetic CI, while at the same time allowing testing against new dependencies, in their own PR, so that if there is any issue after the fact it is also easy to narrow it down to the specific commit that introduced the new dependency version.
cargo update && cargo test has again reproducibility issues, since the result of cargo update depends on the exact point in time at which it is run.

Another reason to revisit this decision is interest in MSRV testing. Until we have a minimal versions resolver feature stablized, the lockfile is the easiest way to emulate it when verifying MSRV in libraries.

I sent a PR to update the book and recommend always using a lock file: https://github.com/rust-lang/cargo/pull/12275

Wanted to add on some more data points around MSRV.
We've seen some people misuse version requirements (rather than using a lock file) to make working with MSRV easier, including:

https://github.com/rust-lang/cargo/issues/6584#issuecomment-1308032517
https://www.reddit.com/r/rust/comments/p8clcx/how_to_fix_cargo_dependency_issue/

Apparently, the version requirement approach is common enough that its a top google search (haven't been able to find it myself)

Some quick Googling suggested that I could explicitly depend on half in my own Cargo.toml, and therefore choose a compatible version there;

See https://www.reddit.com/r/rust/comments/14khqdt/is_there_something_different_about_cargos/
And I've noticed that for winnow that 16 out of 26 dependents exist for MSRV version req hacks.  That number would be higher except I've specifically reached out to some of the dependents and tried to steer them to doing things a different way.

See also a zulip thread from earlier this year
Motivations in addition to MSRV include

Green CI

CI turning red for a PR from an unrelated change is a bad contributor experience

The contributor assumes its their fault and looks into it, wasting their time.  Hopefully they recognize its not their fault.  If they don't, then they waste even more time figuring out how their change broke it
Maintainers need to drop everything and fix it to not make the experience worse for contributors
This is delayed by (detection_time + report_time + maintainer_availability + fix_time + review_time + ci_time_pr + ci_time_bors)

Example: Before cargo had its own lockfile, snapshot tests would fail when human readable output from a dependency changed, causing CI to go red
Example: Before cargo had its own lockfile, CI would turn red if a new dependency was released that deprecated parts of it API (#10742 was also considered for resolving it)
Example: if -Zdirect-minimal-versions (#5657) is merged and people verify it, then a dependency updating a shared dependency can cause a breakage

git bisect

Example: I had to bisect a problem with cargo but found no "root cause" commit.  Most likely, the cause was in some dependency but I couldn't control for that

Documents a "golden stack" for debugging problems
Not being broken by dependencies that yank versions (see also internals)

Downsides with having a policy of checking-in lockfiles

[lib]s CI jobs act as a distributed ecosystem-focused "crater" run.  This puts peer pressure on the ecosystem for fixing bugs and yanking unintended breakages, helping maintain quality and adherence to semver.

Note that this is limited to [lib]-only repos that are following the guideline (e.g. clap checks in its lockfile).  It also only captures the version

Testing the latest dependencies reflects what dependents will be doing

This is also true for workspaces with [[bin]] crates (#7169) but isn't covered in the policy
This is only sampling dependencies at specific times and does not reflect if a dependent is locked to a version that wasn't not covered in CI or newer than the last CI run.  Even worse is bugs can be dependent on the specific versions of dependencies and dependents.

Potential routes

#9930 and #5221
Recommend maintaining a Cargo.lock.msrv

A CI job copies it into place and does verification with --locked (to ensure it isn't stale)
High friction for adding or changing dependencies

Change the Cargo.lock policy to check it in, updating cargo new to not exclude it in the .gitignore file

Recommend either staying up-to-date with dependencies (e.g. Dependabot or RenovateBot) or verify the latest dependencies always work with a job that runs cargo update before doing its verification (whether just cargo check or cargo test)

The verification job should likely be a scheduled job to avoid making CI go red for contributors but Github will auto-disable the full Workflow for all Triggers if it is scheduled and there has been a lull in activity (2 months?), hurting projects that are passively maintained

Also recommend #374 once its available to reduce breaking of dependents

#12275 highlights the approach taken from other ecosystems

Yarn for Node.js

Which files should be gitignored?
[...]

yarn.lock should always be stored within your repository (even if you develop a library).

Poetry for Python

As a library developer
A simple way to avoid such a scenario [testing with latest transitive dependencies] is to omit the poetry.lock file. However, by doing so, you sacrifice reproducibility and performance to a certain extent. Without a lockfile, it can be difficult to find the reason for failing tests, because in addition to obvious code changes an unnoticed library update might be the culprit. [...]
If you do not want to give up the reproducibility and performance benefits, consider a regular refresh of poetry.lock to stay up-to-date and reduce the risk of sudden breakage for users.

Bundler for Ruby

Q: Should I commit my Gemfile.lock when writing a gem?
A: Yes, you should commit it. The presence of a Gemfile.lock in a gem’s repository ensures that a fresh checkout of the repository uses the exact same set of dependencies every time. We believe this makes repositories more friendly towards new and existing contributors. Ideally, anyone should be able to clone the repo, run bundle install, and have passing tests. If you don’t check in your Gemfile.lock, new contributors can get different versions of your dependencies, and run into failing tests that they don’t know how to fix.

@zachw and I met during office hours to discuss their concerns over lockfiles.
This is going to be a rough recollection of the discussion that I'm hoping people find helpful.
There were bad experiences with lockfiles in other ecosystems

"I downloaded a thing; it doesn't work.  I deleted the lockfile; now it works"

For example, the compilers having broken compatibility and new dependency versions are needed to work with the current compiler versions

Lockfiles affecting dependents in node

Someone locked a dependency on something that only used TLS 1.1 (which was no longer being supported by services)

How do we build trust with people who have used similar looking techniques, even if our approach is different?

From this came up a concern:  Would cargo eventually follow node and have lockfiles from dependencies affect dependents?

I don't think this will happen.  The role of a lockfile is for your current project and version requirements are for your dependents
Unsure if any of this is codified.  If not, I might codify it as part of https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Version.20Requirements.20documentation

Testing

Testing a lockfile only tests a specific version

Minimum version requirements might be wrong
Bugs might have happened outside of the locked version that won' be caught

Unfortunately, CI resources are limited (and we can't time travel to test future versions of dependencies), so the question is which combination of dependencies should be tested
At this point, this seems orthogonal to lockfiles (checking in tests one set, not checking-in just tests a different set though it does evolve over time)
If we make a change in our Cargo.lock recommendation, we'd likely also recommend in our CI section for people to have a CI job that first runs cargo update, so people test Cargo.lock + latest

If #5657 was stable, then that too

"Dependanbot"-like bots

These cause extra work and most of it wouldn't be needed if lockfiles didn't exist (some of us would still want automation of upgrading across breaking releases)
For me, I've found RenovateBot took away most of the churn
I also see it beneficial to have PRs for updating the lockfile because I then get CI runs to verify the upgrade worked rather than unpredictable CI failures on unrelated PRs

"I add a dependency on foo and its failing.  I go to contribute a fix to foo and I can't reproduce it"

Yes, for first-time contributors not having a lockfile checked-in produces fewer chances of confusion
However, if its your second time interacting with foo, you can have the opposite experience where your local Cargo.lock from last time can't reproduce a failure in CI for your PR
Ends up being a trade off of which experience you focus on (along with all of the other trade offs)

Is checking-in a lockfile for MSRV just a hack?

Mostly
I started checking in my lockfiles because I found there was no way to maintain my MSRV  policy without doing so
Ideally #9930 would make this need go-away but that is dependent on whether MSRV is set in dependencies

I'll also conservatively say its a year out from stable versions of Rust.  Longer if we have problems getting good error messages

How is it with the experience with old, unmaintained Rust projects?

For dependents, the lockfile doesn't matter
For "CI running latest helps verify new dependencies", the point is moot because CI isn't being run

You could have scheduled jobs but at least for Github, they deactivate the entire workflow if it has a cron trigger

For forking the project, I've just updated dependencies as part of the cleanup and it hasn't been a big deal

@rfcbot fcp merge
I'm recommending we change the policy to always checking-in Cargo.lock while expanding on our CI best practices to suggest having a cargo update && cargo test job (non-blocking for PRs).
Earlier this year, I broached the subject of changing this default on zulip.  Since then I've been seeing a lot more cases of people using version requirements that can break their dependents, partially for the sake of us having a policy to not commit Cargo.lock (example).    In writing guidance in #12323 for people not to use upper-bounds that aren't semver-breaking-aligned, I felt like I really had no alternative solution to offer than to use a Cargo.lock and I just glossed over in the initial draft of that guidance the whole discussion of "bin vs lib" (wrt to Cargo.lock)
Even "bin vs lib" is messy because of workspaces and muilti-crate packages.  For example, I regularly use ignore which lives in the same workspace as ripgrep.
Earlier in this thread I've summarized:

Problems people are having due to this policy (https://github.com/rust-lang/cargo/issues/8728#issuecomment-1610008113)
What we've learned from discussing this in the past (https://github.com/rust-lang/cargo/issues/8728#issuecomment-1610265047)
What other ecosystems are doing (https://github.com/rust-lang/cargo/issues/8728#issuecomment-1612006473)

This is all a matter of trade offs and the question is which set of pros/cons do go with.

Is there a diff of the changes to the recommendations? Would cargo new change?

My expectations

Update the recommendation
Update cargo new
Update CI to encourage testing

What would be the actual guidance for having projects test with latest updates be? If it is to run cargo test && cargo update && cargo test in CI, then it seems like you'll still have problems for contributors. It also seems like asking users to essentially double their CI time would be very significant.

I would expect CI recommendations to be to verify the latest version (at time of run) is still valid for your project in a way that is non-blocking for contributors.
This can happen in one of several ways

A "continue on failure" job in CI

This might might cause noise and slow CI for contributors

A scheduled workflow

If your project updates on a less-frequent basis, your CI host might disable the workflow (e.g. github does this)

A bot that updates all dependencies on a regular basis

The level of verification is dependent on your project,  your dependencies, the level of risk, and CI costs.  A baseline would be to select a representative platform (if the project is platform agnostic) and have a single job on that platform run cargo update && cargo test --all-features.
This means that either the extra jobs might not be part of CI and might be minimal (1 job) so overall CI resources should be minimally impacted.  Similarly, I run only MSRV verification on a single platform but I only do cargo check and not cargo test.

The number of people who are users of a library can be much larger than the number of contributors to it. An inconvenience for the contributors can be overwhelmed by the inconvenience to the users (who are in much less of a position to understand what is wrong).

Which inconvenience are you referring for both the contributors and the users?
For maintainers wanting to maintain an MSRV policy, there options are

Abandon it completely or as a "always update to latest" without any lookback, impacting users relying on the MSRV policy
Maintain a lockfile
Hack up their version requirements, breaking other users

This will be reduced once we get an MSRV-aware resolver in but

That is likely a year out for stable, longer for propagating to enough versions
That doesn't help with dependencies that don't specify an MSRV

For contributors, there is the "inconvenience" of master being red.  I would not classify that as an inconvenience but something that can harm the growth of the project which can hurt the long term maintenance of the project which will hurt users
As for users, an "inconvenience" is that there might be incompatibilities (bugs in a dep, bugs in how caller users dep, actual breaking changes) that could be detected sooner with the current approach.  However, this is dependent on many factors

The last PR for the direct dep to see any issues can be fairly old (ideally most packages are well defined and go into a maintenance mode) so there are many releases in aggregate of dependencies that won't be verified
If I have a lockfile (because I have a bin), I might do some action that upgrades the indirect dep without updating the direct dep for any changes it might need

Since cargo doesn't have an --unlocked flag, testing in some environments with updates can be awkward or impossible due to read-only mounting.

How theoretical is this or are you aware of the scope of how much people do this?  This can give us an idea of how much we need to define general recommendations around it, including caveats, or leaving it to them to figure out how to adapt guidance to an esoteric environment.
I would also expect a place doing this is likely also creating binaries and they would already run into this problem.

I would be much less concerned about changing recommendations if cargo did semver checks during publish. That wouldn't help with behavioral breakage, but could cover a significant amount of post-publish breakage.

This is nice in theory but, as I pointed out earlier, the scope of people benefiting from the "distributed crater" is limited and is likely shrinking as people are feeling the pain of MSRV or non-reproducible builds and are checking in lockfiles.
Where this isn't being limited, there are other workarounds going in place that are far worse, like restricting the upper bounds on version requirements.  As I pointed out earlier, as one example of the scope of this is that more than half of winnow's direct dependents are pinning the version in their Cargo.toml.  Not being familiar with all of the projects, its not quite clear to me when some of them may be depended on, so I can't filter that number down for how many could be breaking their dependents.
This is also creating a situation where people "in the know" do one thing while newer users or users less confident in breaking away from guidelines are dealing with the problems and likely solving them in the wrong way.

Having deterministic / reproducible CI runs could equally be achieved by capturing the Cargo.lock as a workflow artifact.
For testing with your MSRV, a common recommendation is to check in a Cargo.lock.msrv that gets used only for the specific runs that test with an old Rust version. It thus has no bearing on whether a normal Cargo.lock should also be checked into the repository.
It seems like a main goal of this suggestion is to keep CI green more often. And it does so by having nearly all your CI runs repeatedly testing against pinned dependency versions rather than running against newer versions that would be more likely to discover bugs and turn CI red. That... seems backwards to me?

It seems like a main goal of this suggestion is to keep CI green more often.

That's only partially true. Both the original post and later posts mention build reproducibility which is useful for other reasons than just CI. In particular all things debugging related, like git bisect or debugging between multiple developers.

rather than running against newer versions that would be more likely to discover bugs

Also, note that my proposal includes encouraging people to regularly test the latest versions of their dependencies in some way.  See https://github.com/rust-lang/cargo/issues/8728#issuecomment-1623921676 for more details

A bunch of the arguments here would also apply to checking in a rust-toolchain.toml file. My understanding is that this isn't very common across the ecosystem, but it raises the question of whether it should be?

 My understanding is that this isn't very common across the ecosystem, but it raises the question of whether it should be?

IMO yes, in fact ideally a completely deterministic nix configuration should be checked in in every project (regardless of its language(s)).

Which inconvenience are you referring for both the contributors and the users?

The inconvenience I'm thinking of for a contributor is: I push a change, CI is red, I spend a few minutes to figure it out and push a fix and move on (possibly reporting a bad semver update in a dependency). My expectation, based on the issues I've experienced, is that this takes relatively little time.
The inconvenience for a user is that they try to add your crate to their project (or update to a new version), and it fails because of some issue (like an broken semver update). They hit a roadblock that they either don't understand, or don't know how to fix, or need to spend time tracking down, informing some dependency that something is wrong (though they might now know which one). My experience, based on seeing user reports, is that some people get confused or frustrated, and may not be in a position to understand how to fix the problem.

How theoretical is this or are you aware of the scope of how much people do this? This can give us an idea of how much we need to define general recommendations around it, including caveats, or leaving it to them to figure out how to adapt guidance to an esoteric environment.

rust-lang/rust runs with read-only mounts, and wouldn't be able to test unlocked libraries. My understanding is that it is not too uncommon to mount the source tree in read-only mode with Docker.

I'm very much in favor of updating the documentation to make to tradeoffs clearer to the user, and to provide suggestions on how to keep their project in a healthy state (like using dependency bots, scheduled jobs, different CI strategies, etc.). I think it should be made clear to users that it isn't wrong to check in Cargo.lock, or that it has any impact to users (other than the hazards of not testing latest version). I think it might also be good to put some suggestions for the cargo publish workflow to consider testing against latest versions. I'm less confident about specifically changing the default behavior (like cargo new) until cargo has better facilities for testing and verification.

The "distributed crater" idea is very disappointing. By the time a semver-incompatible library is published, it's already too late. Following semver is the responsibility of the crate maintainer, not its users. The fact that CI can be abused to test for semver incompatibilities is a happy accident, it's not what the ecosystem needs for addressing the problem.
My suggestion for that is encouraging semver compatibility tests in CI, e.g. cargo public-api or cargo semver-checks. [^1] I don't know the effectiveness of these tools, but even if they catch just over than half of common problems it could have a bigger positive impact than "distributed crater" with less accidental work (toil) for maintainers of other projects.
[^1]: There is also https://github.com/rust-lang/rust-semverver, which is deprecated and links to the other two projects as potential alternatives.

FYI #374 is for tracking automated semver checking (for what can be checked).

I've updated my earlier comment with the various trade offs that have been discussed.
If we do this, we should decide what the appropriate level of communication is.  For example, should this be an Inside Rust blog post?
To make the proposal more concrete, I'm going to include a rough draft of the PR description and the documentation changes.  The intent is to not  nitpick the language (the PR will be for that) but to give people a more concrete idea of what is being proposed (and to nitpick that)

PR Description
fix: Change the defaults to always check-in Cargo.lock
Having libraries leave Cargo.lock "on the float" has been serving the ecosystem well, including

Encouraging people to validate latest dependencies work
Encouraging ecosystem-wide health by acting as a "distributed crater"

These benefits are limited though.  The policy is inconsistent between workspaces with or without [[bin]]s, reducing the affect of testing the latest.  This is also subject to when CI last ran; for passively maintained projects, there is little coverage of new dependencies.
There are also costs associated with this policy

git bisect is using an unpredictable set of dependencies, affecting the ability to identify root cause
This is another potential cause for Red CI / broken local development if version is yanked or a bug is introduced

Impacting the perceived level of quality for a project
Confusing to new contributors who might not recognize why CI failed and assume its their fault
Requiring context switching from maintainers to get fixes in

In particular, since this policy was decided, there has been an increased interest in supporting an MSRV (as recently as v1.56.0, cargo gained support for specifying a package's MSRV).   This has led to fatiguing discussions on what MSRV a package should use (e.g. https://github.com/rust-lang/libs-team/issues/72,. https://github.com/time-rs/time/discussions/535).  Worst, there has been a growing trend for people to set an non-semver upper bound on dependencies, making it so packages can't work well with other packages.  Tooling support would help with this (#9930) but the sooner we address this, the less entrenched bad practices will be.
On the positive side, since the policy was decided

In general, CI became easier to setup and maintain with Github Actions compared to TravisCI
Dependabot went GA on Github in 2021 (https://github.blog/changelog/2021-03-31-dependabot-version-updates-are-now-generally-available)

I believe Dependabot will post security update PRs even when Dependabot is not more generally enabled

So to get some of the benefit from not checking in Cargo.lock, we can recommend either automatically applying updates or having CI check the latest dependencies in a way to get this out of the critical path of PRs and releases.
Since there is no one right answer on how to solve all of these problems, we're documenting these trade offs so people can make the choice that is most appropriate with them.
Prior art

Yarn (Javascript)
Poetry (Python)
Bundler (Ruby)

Cargo.toml vs Cargo.lock
Old:

If you’re building a non-end product, such as a rust library that other rust packages will depend on, put Cargo.lock in your .gitignore. If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git. If you’re curious about why that is, see “Why do binaries have Cargo.lock in version control, but not libraries?” in the FAQ.

New:

When in doubt, check Cargo.lock into git. For a better understanding of why and what the alternatives might be, see “Why have Cargo.lock in version control?” in the FAQ.  We recommend pairing this with Verifying Latest Dependencies (link to new CI section, see below)

Why do binaries have Cargo.lock in version control, but not libraries?
Why have Cargo.lock in version control?
While cargo new defaults to tracking Cargo.lock in version control, whether you do is dependent on the needs of your package.
The purpose of a Cargo.lock lockfile is to describe the state of the world at the time of a successful build. Cargo uses the lockfile to provide deterministic builds on different times and different systems, by ensuring that the exact same dependencies and versions are used as when the Cargo.lock file was originally generated.
Deterministic builds help with

Running git bisect to find the root cause of a bug
Ensuring CI fails due to new commits and not external factors
Reducing confusion when contributors see different behavior as compared to other contributors or CI

Having this snapshot of dependencies can also help when projects need to be verified against consistent versions of dependencies, like when

Verifying a minimum-supported Rust version that is less than the what latest version of a dependency supports
Verifying human readable output which won't have compatibility guarantees (e.g. snapshot testing error messages to ensure they are "understandable", a metric too fuzzy to automate)

However, this determinism can give a false sense of security because Cargo.lock does not affect the consumers of your package, only Cargo.toml, for example:

cargo install will select the latest dependencies unless --locked is passed in (see #7169)
New dependencies added via cargo add will be locked to the latest version

For strategies to verify newer dependencies, see Verifying Latest Dependencies

In a new Reference-level CI page that the CI guide links to
Continuous Integration
Verifying latest dependencies
When specifying dependencies in Cargo.toml, a range of versions are possible.  Testing every possible version combination would be unwieldy.  At minimum, it would help dependents of your package to at least verify the latest versions.
When testing the latest versions some considerations are:

Minimizing external factors affecting local development or CI
Rate of new dependencies being published
Level of risk a project is willing to accept
CI costs, including indirect costs like if a CI service has a maximum for parallel runners, causing additional jobs to be serialized when affected

Some potential solutions include:

Not checking in the Cargo.lock (links to FAQ)

Depending on PR velocity, many versions may go untested
This comes at the cost of determinism

Have a CI job verify the latest dependencies but mark it to "continue on failure"

Depending on the CI service, failures might not be obvious
Depending on PR velocity, may use up more resources than necessary

Have a scheduled CI job to verify latest dependencies

A hosted CI service may disable scheduled jobs for repositories that haven't been touched in a while, affecting passively maintained packages
Depending on the CI service, notifications might not be routed to people who can act on the failure
If not balanced with dependency publish rate, may not test enough versions or may do redundant tests

Regularly update dependencies through PRs, like with Dependabot or RenovateBot

Can isolate dependencies to their own PR or roll them up into a single PR
Only uses the resources necessary

An example CI job to verify latest dependencies, using Github Actions:
jobs:
  latest_deps:
    name: Latest Dependencies
    runs-on: ubuntu-latest
    continue-on-error: true
    steps:
      - uses: actions/checkout@v3
      - run: rustup update stable && rustup default stable
      - run: cargo update --verbose
      - run: cargo build --verbose
      - run: cargo test --verbose

For projects with higher risks of per-platform or per-Rust version failures, more combinations may want to be tested.

I've posted #12382 for this.  It is a draft while we wait for the final comment period.

I think the "What should Cargo.lock represent as opposed to Cargo.lock.<topic> if used?" related question needs to be answered at the same time the rest of this proposal is.
Right now there seems to be some switching back and forth between Cargo.lock meaning a "nearly current version of all dependencies" (maintained via Dependabot or similar) or "versions that work with your crate's MSRV" (which is useful to track but can't be automated without the relevant tooling becoming msrv aware).

I think the "What should Cargo.lock represent as opposed to Cargo.lock. if used?" related question needs to be answered at the same time the rest of this proposal is.

I don't think we need one answer for this.  The Cargo.lock is a snapshot of what works at a given time.  There can be different motivations for different projects for what that snapshot should reflect and if more than one snapshot is needed.

Right now there seems to be some switching back and forth between Cargo.lock meaning a "nearly current version of all dependencies" (maintained via Dependabot or similar) or "versions that work with your crate's MSRV" (which is useful to track but can't be automated without the relevant tooling becoming msrv aware).

This is because the answer is "it depends".  There are multiple strategies for how you test latest and how you test MSRV.  We are leaving that in users hands to make a decision.  We aren't saying you have to use Dependabot and keep all dependencies at latest.

The guidelines should list out what strategies there are to pick from, and the associated trade-offs. Instead, the draft text just has a co-mingled list of benefits from different strategies without clarifying that some are mutually incompatible. (It also strongly implies that certain benefits are only possible by checking in a Cargo.lock, which as has been discussed a few times in this thread, isn't true)

Please be more specific as with that I have no idea which parts you are referring to and can't act or respond.

All the discussion around Cargo.lock.msrv that didn't make it into any of the draft guidelines

And "Why have Cargo.lock in version control?" for a place that's assuming specific strategies without saying so

Please provide more detail than that.  I feel like you have a specific set of ideas in mind but I have not been able to discern them from what has been said so far.
I am well aware of the past conversations and I just re-read the new FAQ entry that is in #12382.  I'm not quite seeing what you are referring to.

I give up. I cited a specific section ("Why have Cargo.lock in version control?") of your previous comment that lists benefits of checking in Cargo.lock but assumes a Cargo.lock = MSRV strategy will be used, without saying so. I also give a specific topic ("Cargo.lock.msrv") that was discussed here, but isn't mentioned in the PR description or the FAQ changes

I would like to offer a counterpoint against checking in the Cargo.lock file in the repository.
While there are valid arguments for including it, there are also considerations against doing so:

Conflicts between branches: When working with different branches, conflicts can arise due to changes in dependencies within the branches. Checking in the Cargo.lock file can lead to conflicts when merging or switching between branches.

Noise in commits and pull requests: Including the Cargo.lock file in version control can clutter the commit history and pull requests with unnecessary changes. The frequent changes in the Cargo.lock file create noise.

Testing with the latest dependencies: This has already be said, but it is essential to test code with the latest dependency versions as that is what users will ultimately experience.
This ensures any potential issues arising from dependency incompatibilities are detected early, allowing proactive actions, such as releasing new versions of the crate to avoid roadblocks for users.

Regarding MSRV workaround, I've added cargo update --precise in my CI: https://github.com/slint-ui/slint/blob/e9286c11890a66e39b1779b7f20854d65baaf9b9/.github/workflows/ci.yaml#L70

Thanks @ogoffart with this info! Will be updating the PR with merge conflicts and what I'm about to say.
The purposed change is from cargo telling people what to do to giving them a starting point, or default, and giving them the information to make their own choice, if needed.
So the question for defaults is who are we targeting? For a default path in documentation, it would be for new to intermediate users. By the time you form a company around a large [workspace], you are more likely to be in a position to make a choice that works for you and its more likely it will be bespoke.
As for cargo new, we've been prioritizing new users over those that run it frequently (boiler plate comment, bin is default, etc).

FCP is finished but we will be waiting until the next beta branch is created before moving forward so we get a full 12 weeks of feedback.

This fiasco is possibly related: https://github.com/rust-lang/rust/issues/113152#issuecomment-1699673552 . Nearly all my binary projects created nearly May 2023 (assuming they have Cargo.lock) don't build anymore. Removing Cargo.lock fixes them

@safinaskar That breakage is unrelated to Cargo.lock; it is caused by a change to the nightly compiler. You can either build with the latest stable compiler (as mentioned in a response to your comment on that ticket) or, more appropriately perhaps, pin your nightly version with a toolchain file.

(or try to apply pressure on crate authors to not silently opt their users into unstable breakage simply because they use a nightly compiler)

I agree with @Nemo157  that that was a bug in proc-macro2 to use nightly features without a users consent (usually a unstable or nightly feature flag).

suggest relying on https://dependabot.com/rust/

Note that dependabot uses the existence of Cargo.lock as a heuristic that a crate is an application. The behaviour seems not configurable, and by default means a library-with-a-lockfile will churn dependency versions forwards in the Cargo.toml.

This might be a good incentive to open an issue about having that configurable in dependabot, it's a big reason I don't use it on most of my repos.

The primary reason I switched to RenovateBot was to make dependency updating faster (dropped my monthly updates from a couple days to part of a day) but the greater control was a close second.  For example, here is the config for clap