Better handling of splatted keyword arguments and with_collection

Feature request
Allow components to have unnamed keyword arguments when using with_collection
Motivation
This would allow using generic initialize methods with unnamed parameters and provide more flexible opportunities for composition, especially in regards of DRYing up initializers.
Also, I can imagine, this would become a necessity with #2004
Details
Currently these scenarious are not possible:
Example 1: (concept from ViewComponentContrib)
class ApplicationViewComponent < ViewComponent::Base
  extend Dry::Initializer[undefined: false]
end

class ButtonComponent < ApplicationViewComponent
  option :button

  erb_template <<~ERB
    <%= button.inspect %>
  ERB
end

NB: extend Dry::Initializer adds this method definition:
def initialize(...)
  __dry_initializer_initialize__(...)
end

(... is verbatim Ruby code)
Example 2: (meta programming)
module InitHelpers
  extend ActiveSupport::Concern

  class_methods do
    def record_name = name.demodulize.underscore.chomp("_component").to_sym
  end

  included do
    attr_reader self.record_name
  end

  def init_component(**options)
    attr = self.class.record_name
    instance_variable_set(:"@#{attr}", options[attr])
  end
end

class AvatarComponent < ViewComponent::Base
  include InitHelpers

  def initialize(**)
    init_component(**)
  end

  erb_template <<~ERB
    <%= avatar.inspect %>
  ERB
end

There is an explicit check to exclude unnamed keyword arguments:
https://github.com/ViewComponent/view_component/blob/66dcb7cc9956a52cbbd7fb12de98b90affd756e4/lib/view_component/base.rb#L695-L698
I did some rummaging and found this commit https://github.com/ViewComponent/view_component/commit/56a6560160795b5941ff67edcb56ea0878ae17fa It mentions that Ruby 3.1 def m(*) might implicitly be the same as def m(*,**)
If that's actually the case it does make sense to forbid unnamed splatted kwargs, but I assume this check can be relaxed for other Ruby versions.
PR
I'm happy to make a PR, but first I want to discuss the proper way to do this, especially considering the fact, that removing the check might introduce subtle bugs.

@daniel-rikowski would you be able to add some failing tests that we could use as a spec

@reeganviljoen How shall I approach this? Do you want me to create a PR with just the failing tests? Or shall I post them here before?
Anyway, I think I found the root cause.
If you have a component without an initialize method, instance_method(:initialize) in this line
https://github.com/ViewComponent/view_component/blob/66dcb7cc9956a52cbbd7fb12de98b90affd756e4/lib/view_component/base.rb#L708-L710
returns ActionDispatch::Routing::UrlFor#initialize(...). 😮
This stems from the ActionView::Base parent class of all view components. (I have no idea why this doesn't return ViewComponent::Base#initialize or ActionView::Base#initialize.)
In other words: Without an overridden initialize method, the splatted_keyword_argument_present? method actually checks ActionDispatch::Routing::UrlFor#initialize. (So no Ruby bug 😌 😄)
The following change does seem to fix the whole problem (still, some tests need to be adapted)
      def initialize_parameters
        # Instead of:
        # @initialize_parameters ||= instance_method(:initialize).parameters
        # This:
        @initialize_parameters ||=
            instance_method(:initialize).then { |m| m.owner < ViewComponent::Base ? m.parameters : [] }
      end

@daniel-rikowski i have been quite busy lately but I will see if I can find some time to add failing tests and then your research should really come in handy

I invested a few hours over the weekend. Although the failing tests and the fix are fairly simple, I can't figure out when or why instance_method(:initialize) returns ActionDispatch::Routing::UrlFor#initialize(...) instead of ViewComponent::Base#initialize(*).
Here's are failing tests:
# frozen_string_literal: true

require "test_helper"

module ViewComponent
  class UnnamedArgumentsTest < TestCase
    class DynamicComponentBase < ViewComponent::Base
      def setup_component(**attributes)
        # This method is somewhat contrived, it's intended to mimic features available in the dry-initializer gem.
        model_name = self.class.name.demodulize.delete_suffix('Component').underscore.to_sym
        instance_variable_set(:"@#{model_name}", attributes[model_name])
        define_singleton_method(model_name) { instance_variable_get(:"@#{model_name}") }
      end
    end

    class OrderComponent < DynamicComponentBase
      def initialize(**)
        setup_component(**)
      end
      def call
        "

#{order.number}

".html_safe
      end
    end

    class CustomerComponent < DynamicComponentBase
      def initialize(...)
        setup_component(...)
      end
      def call
        "

#{customer.name}

".html_safe
      end
    end

    def setup
      @customers = [OpenStruct.new(name: "Taylor"), OpenStruct.new(name: "Rowan")]
      @orders = [OpenStruct.new(name: "O-2024-0004"), OpenStruct.new(name: "B-2024-0714")]
    end

    def test_supports_components_with_argument_forwarding
      render_inline(CustomerComponent.with_collection(@customers))
<EMAIL_ADDRESS>text: @customers.first.name)
<EMAIL_ADDRESS>text: @customers.last.name)
    end

    def test_supports_components_with_unnamed_splatted_arguments
      render_inline(OrderComponent.with_collection(@orders))
<EMAIL_ADDRESS>text: @orders.first.number)
<EMAIL_ADDRESS>text: @orders.last.number)
    end
  end
end

and this is the fix:
module ViewComponent
  class Base < ActionView::Base
    class << self
      def splatted_keyword_argument_present?
        # initialize_parameters.flatten.include?(:keyrest) &&
        #   !initialize_parameters.include?([:keyrest, :**]) # Un-named splatted keyword args don't count!
        initialize_parameters.flatten.include?(:keyrest)
      end
    end
  end
end

BUT:
Now RenderingTest#test_collection_component_missing_default_parameter_name fails.
That component has no own initialize method:
class MissingDefaultCollectionParameterComponent < ViewComponent::Base
  def call
  end
end

So it doesn't (=shouldn't) accept a collection argument and the test verifies, that ViewComponent detects this.
But in this case it fails, because instance_method(:initialize) returns ActionDispatch::Routing::UrlFor#initialize(...) which does accept it.
In other words:
instance_method(:initialize) returns #<UnboundMethod: ActionDispatch::Routing::UrlFor#initialize(...) >
method(:initialize) is #<Method: #<Class:MissingDefaultCollectionParameterComponent>(Class)#initialize(*)>
I have no idea why this happens, or how to circumvent it. My original idea to check instance_method(:initialize).owner < ViewComponent::Base would work, but that would also disable any initialize method coming from a module, e.g. Dry::Initializer.
I tried to reproduce this with minimal code, but I was unable to define a class in which instance_method(:initialize) and method(:initialize) pointed to different methods. I guess my Ruby knowledge is just limited here.

Thanks for referring to my abstract components issue. Reviewing what you have here, I'm not sure what you are suggesting is ideal. There is some merit in avoiding duplication via the DynamicComponentBase class, but there's actually a good reason why I suggest creating the base components. This is because the base component works really good as a place to put helper methods and other things that may be used across components that use the same base component. Concerns are a better solution for helpers not limited to a specific kind of input.
Indeed, rather than adding a dynamic base class. It is probably more helpful to modify the generators or make it easier to create your own custom generators that make use of dry-effects if you want.
Here is how I would implement the OrderComponent and CustomerComponent you had. I used two different ways of handling "data_key" and "data_value". The first moves it to the base class, and the other just handles the key and value inline.
class DesignSystem::H1Component < Record::BaseComponent
  attr_reader :key, :value

  def initializer(key:, value:)
    @key = key
    @value = value
  end

  def call
    "

#{value}

".html_safe
  end
end

class Order::BaseComponent < ApplicationComponent
  attr_reader :order

  def initialize(order:)
    @order = order
  end

  def data_key
    :number
  end

  def data_value
    order.number
  end
end

class Order::H1Component < Order::BaseComponent
  def call
    DesignSystem::H1Component.new(key: data_key, value: data_value)
  end
end

class Customer::BaseComponent < ApplicationComponent
  attr_reader :customer

  def initialize(customer:)
    @customer = customer
  end
end

class Customer::H1Component < Customer::BaseComponent
  def call
    DesignSystem::H1Component.new(key: :name, value: customer.name)
  end
end

However, to solve the original issue, I did have ChatGPT assist with quickly generating a solution that uses class_eval. Though I used it for the example above, so it will work with things like: Customer::TableComponent.new(customer:) and Customer::Invoice::TableComponent.new(customer_invoice:). It also works with Customer::Invoice::TableComponent.new()  which is the same as Customer::Invoice::TableComponent.new(customer_invoice: nil)
class DynamicComponentBase < ViewComponent::Base
  def self.inherited(subclass)
    super
    subclass.class_eval do
      parts = name.split("::").map(&:underscore)
      parts = parts[0..-2] if parts.size > 1
      component_name = parts.join("_")

      attr_reader component_name

      define_method(:initialize) do |**args|
        instance_variable_set("@#{component_name}", args[component_name.to_sym])
      end
    end
  end
end

Might actually use it myself to dry up the places where an initializer isn't need.

@MyklClason Now I feel bad, because you put so much work into your answer 😩
The code from the test was actually just intended to mimic some of the functionality of dry-initializer without introducing that gem as a new dependency into the test suite. I'm not looking for new ways to implement these features.
In a nutshell, I want to have this, more or less: https://github.com/palkan/view_component-contrib#hanging-initialize-out-to-dry
I.e. do this...
class ApplicationViewComponent
  extend Dry::Initializer
end

class CustomerComponent < ApplicationViewComponent
  option :customer
end

... and be done with it.
But ViewComponent actively prevents these components to be used in a collection.
(They need to have an explicit initialize method with named arguments, while a major purpose of dry-initializer is getting rid of said methods.)

Anyway, even if it is decided, that my use case is not worth the trouble, it is still a possibility, that some day the Rails developers change the signature of the method, which made this whole workaround necessary.
E.g. they change ActionView::Routing:UrlFor#initialize from this
def initialize(...)
  @_routes = nil
  super
end

to - let's say - this:
def initialize(*, **options)
  @_routes = nil
  @_options = options
  super
end

(Unlikely, admittedly, but it is a possibility.)
Then, the afformentioned parameters check would no longer help in preventing misconfigured components, because then, many components get their named splatted arguments from ActionView::Routing:UrlFor#initialize (Without their developers ever knowing...)
IMHO this is a much deeper problem than just preventing certain component class definitions.

Lol, no problem. My initializers are more DRY now lol. So I'm happy enough.
However, isn't isn't that what the last edit did?
class ApplicationViewComponent
  include BaseComponentInitializer # extend Dry::Initializer
end

class CustomerComponent < ApplicationViewComponent
  base_initializer :customer # option :customer
end

Of course, you can change the method name so it uses "option" instead of "base_initializer".
I have seen the "_routes" you mention, but I just ignore it.
Here is a version that in theory mimics what you( had except it uses "include" rather than "extend". Been a while since I looked into the differences of those.
module Dry::Initializer
  extend ActiveSupport::Concern

  included do
    def self.option(*attributes)
      class_eval do
        attr_reader *attributes

        define_method(:initialize) do |**kargs|
          attributes.each do |attribute|
            instance_variable_set("@#{attribute}", kargs[attribute.to_sym])
          end
        end
      end
    end
  end
end

class ApplicationViewComponent
  extend Dry::Initializer
end

class CustomerComponent < ApplicationViewComponent
  option :customer
end


Missing index signature when using passthrough() and infer()

I’ve tried to update my projects from using zod v1 to zod v3. Unfortunately it seems like passthrough() does’t work in the same way as nonstrict() did before.
Example:
const foo = z.object({ foo: z.string() }).passthrough();
type Foo = z.infer<typeof foo>;

The inferred type Foo is now { foo: string; }, but since I want to allow unrecognized keys I would expect something like { foo: string; [key: string]: unknown; }.
Example with zod v1:
const foo = z.object({ foo: z.string() }).nonstrict();
type Foo = z.infer<typeof foo>;

The inferred type Foo is here { [x: string]: any, foo: string }.

I’ve just learned about catchall() in zod v3, which adds an index signature to the inferred type. I guess this would work for my case.
The question is, what would be the expected behavior for passthrough() here?

Fixed in 3.3.2.
BTW Mathias, I just merged the  big performance enhancement PR in 3.3.2 so Zod's 200x faster now 😛

Awesome @colinhacks. Thank you!

we're good with .catchall(z.unknown()) (the correct type can be inferred):
const foo = z
  .object({
    id: z.string().optional(),
  })
  .catchall(z.unknown());

type Foo = z.infer<typeof foo>; // { [x: string]: unknown; id?: string; }

should .passthrough() has the same index signature? since their behavior looks the same. currently .passthrough() will not add [x: string]: unknown; to the inferred type.


making menu declarative

this adds a declarative open prop to menu and adds events as props too

I kinda figured out that while we are a wrapper for preact, its good to expose the underlying API in the declarative way preact/react devs are used to. moreover its still a wrapper over underlying API.
still custom code is kept to min


Better support for libraries component within component model.

What problem does this feature solve?
In some libraries I've seen this particular pattern
<parent>
  <child></child>
  <child></child>
</parent>

Where both components are provided by a library similar to <li> inside of <ul>. However, this presents a number of problems. Here is a non-exhaustive list of things I've noticed.

The primary problem is communication between components is impossible with standard techniques. Props and custom events only work with direct parent and child component relationships which these are not.
Inserting new child components into a parent component. The example I was thinking of is if you want to show popup or snackbar alerts for a SPA where in the root component you have a parent component that handles positioning and manages all the messages. Then you have a child component that contains information specific to each message. It would be nice to be able to push a new child component into the parent component from anywhere in the SPA, but I don't see an intuitive way to do this. (Also, one reason you might want to have a full child component instead of just text pushed onto a list is so that you can customize each messages with possibly child components or other DOM markup).
Another thing that can happen when using this pattern is when you have a couple different child components that are meant for a single container component. Right now to distinguish between them you also need to set a slot unique to each type of child component so that the parent can distinguish between them which seems redundant. It seems like it would be useful to have something similar to the $slots, but for children custom components.

What does the proposed API look like?
For point 1 perhaps something like provide/inject would help, but it doesn't solve the problems of passing events back up to the parent.
Point 2 I'm not sure the best way to solve this perhaps someone else has an elegant way of solving this problem.
For point 3 I think it could be as simple as adding something like $childComponents.childComponentName.

The cleanest pattern for "communicating" between <parent> and <child> is no communication at all - let both be driven by the state from the common parent. If that is somehow not feasible, then <parent> and <child> are most likely tightly-coupled by nature, and in that case calling $parent.$emit() inside <child> is ok.

Something like this might help:

<msg-container>
   <msg v-for="msg in msgs" :msg="msg"/>
</msg-container>

You can achieve this by using render functions, and filtering/grouping $slot nodes programmatically.

@yyx990803 Here is pseudo code of what I was thinking for an alert system, but I don't see any way to do this with the current methods
/*index*/
<alert-con></alert-con>

//router links for page1 page2 etc
<router-view></router-view>

/*page1*/
//An asynchronous success message
addAlert(`<alert fade="4e3">Submitted Successfully</alert>`)

/*page2*/
addAlert(`<alert warning="true" onClose="completeDeleteCallbackFn">Deleted! <button @click=undo><icon>Undo</icon></button></alert>`)

/*globally*/
addAlert(`<alert height="double"><avatar id="foo"></avatar> John Doe is online.</alert>`)
addAlert(`<alert autoClose="false">You have {{unreadMessageCount}} new <a href="/messages">message{{unreadMessageCount>1:'s':''}}</a></alert>`)

About point 3 I have been using the render function. But the problem is slots returns the results of the h() call not a Vue component which isn't documented very well. The developer then has to handle a bunch of edge cases such as empty text nodes, non-empty text nodes, normal HTML and perhaps some other cases I haven't run into yet. It seems like there should be a better way of sorting content hence why I was suggesting something similar to slots but by tag name.
this.$slots.default.forEach(v=>{
      //Checks for empty text nodes
      if(v.tag==undefined&&v.text==undefined)return;
      //checks to see if it is normal html or non-empty text nodes
      if(v.componentOptions==undefined){
        defaultCon.push(v);
        return;
      }
      let tag=v.componentOptions.tag
      //Now you can sort by tag

An example of an alert component that can take strings, components and render fns: https://jsfiddle.net/fvv3848b/


Is there a way to generate the spreadsheet?

Is there a way to generate the .xlsx document?
Use case -
I have a file in resources/lang/fr.json with `{ ... "Title": "", ... }
I would like to be able to create the spreadsheet from that file.
Send it to the translation team.
Update the file and import the translations.
What are your thoughts on that?

I don't think it has a use case for this package. Because it is a one-time thing you need to generate, after that it is not useful anymore. But here's the code I used when we first migrated from file-based translations to Excel.
$translator = app('translator');
$translator->load('*', '*', 'fr');

$loaded = new \ReflectionProperty($translator, 'loaded');
$loaded->setAccessible(true);
$translations = $loaded->getValue($translator)['*']['*']['fr'];

$translations here will have an array translations list for the fr locale using the array key as the translation key and the array value as the actual translation. You can use it to generate your own one-time Excel spreadsheet.

Hmm yeah, I get your reasoning on that, thanks.
What if we want continuous working on the file? For example, in the initial stage, I'd export all EN and FR into a spreadsheet, send it to my team for translation, and then I will import it back to my application. At a later stage when new functionality is introduced and new language strings are to be translated I'd want to have a way to export again with all current translations and the new string so that can be again sent to my team.
Hope that makes sense and justifies my original question/request.


Germanic sounding translation in middle of pack

Translations generally good, but this line is very odd:
"Reload Data","Daten neuladen",module,Magento_Backend

I suspect that the translation is actually... "Reload Data"

also Miktar ve öğeleri güncelle in there 3 times


using Jetson Nx  error

(torch_env) inspur@inspur-desktop:~/torch_long/yolact_edge$ python eval.py --trained_model=/home/inspur/torch_long/yolact/weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --image=/home/inspur/torch_long/yolact/1.jpg:output_image.png
Config not specified. Parsed yolact_edge_config from the file name.
[02/01 11:33:58 yolact.eval]: Loading model...
/home/inspur/torch_long/torch_env/lib/python3.6/site-packages/torch/jit/_recursive.py:165: UserWarning: 'lat_layers' was found in ScriptModule constants,  but it is a non-constant submodule. Consider removing it.
" but it is a non-constant {}. Consider removing it.".format(name, hint))
/home/inspur/torch_long/torch_env/lib/python3.6/site-packages/torch/jit/_recursive.py:165: UserWarning: 'pred_layers' was found in ScriptModule constants,  but it is a non-constant submodule. Consider removing it.
" but it is a non-constant {}. Consider removing it.".format(name, hint))
/home/inspur/torch_long/torch_env/lib/python3.6/site-packages/torch/jit/_recursive.py:165: UserWarning: 'downsample_layers' was found in ScriptModule constants,  but it is a non-constant submodule. Consider removing it.
" but it is a non-constant {}. Consider removing it.".format(name, hint))
[02/01 11:34:08 yolact.eval]: Model loaded.
[02/01 11:34:08 yolact.eval]: Converting to TensorRT...
Traceback (most recent call last):
File "eval.py", line 1241, in
convert_to_tensorrt(net, cfg, args, transform=BaseTransform())
File "/home/inspur/torch_long/yolact_edge/utils/tensorrt.py", line 76, in convert_to_tensorrt
calibration_dataset = pull_calib_dataset(calib_images)
File "/home/inspur/torch_long/yolact_edge/utils/tensorrt.py", line 63, in pull_calib_dataset
calibration_dataset = torch.stack(images)
RuntimeError: stack expects a non-empty TensorList
########################
Who can answer me?

You did not download the calibration images for INT8 conversion. See here.

You did not download the calibration images for INT8 conversion. See here.

Thanks for your quick reply, we have solved this problem, but there is another problem when running  eval.py.

[02/01 16:13:45 yolact.eval]: Loading model...
[02/01 16:13:54 yolact.eval]: Model loaded.
[02/01 16:13:54 yolact.eval]: Converting to TensorRT...
[02/01 16:15:08 yolact.eval]: Converting backbone to TensorRT...
[TensorRT] ERROR: FAILED_ALLOCATION: std::bad_alloc
Traceback (most recent call last):
File "eval.py", line 1241, in
convert_to_tensorrt(net, cfg, args, transform=BaseTransform())
File "/home/inspur/torch_long/yolact_edge/utils/tensorrt.py", line 152, in convert_to_tensorrt
net.to_tensorrt_backbone(cfg.torch2trt_backbone_int8, calibration_dataset=calibration_dataset, batch_size=args.trt_batch_size)
File "/home/inspur/torch_long/yolact_edge/yolact.py", line 1571, in to_tensorrt_backbone
self.trt_load_if("backbone", trt_fn, [x], int8_mode, batch_size=batch_size)
File "/home/inspur/torch_long/yolact_edge/yolact.py", line 1554, in trt_load_if
self.save_trt_cached_module(module, module_name, int8_mode, batch_size=batch_size)
File "/home/inspur/torch_long/yolact_edge/yolact.py", line 1545, in save_trt_cached_module
torch.save(module.state_dict(), module_path)
File "/home/inspur/torch_long/torch_env/lib/python3.6/site-packages/torch/nn/modules/module.py", line 902, in state_dict
hook_result = hook(self, destination, prefix, local_metadata)
File "/home/inspur/torch_long/torch_env/lib/python3.6/site-packages/torch2trt-0.1.0-py3.6-linux-aarch64.egg/torch2trt/torch2trt.py", line 419, in _on_state_dict
state_dict[prefix + "engine"] = bytearray(self.engine.serialize())
TypeError: 'NoneType' object is not iterable
段错误 (核心已转储)

Can you help me?

Did you install the TensorRT and PyTorch with the version in INSTALL.md? If not, what is the version you are using? Can you try running without TensorRT (--disable_tensorrt) and use FP16 only (--use_fp16_tensorrt)?

Did you install the TensorRT and PyTorch with the version in INSTALL.md? If not, what is the version you are using? Can you try running without TensorRT (--disable_tensorrt) and use FP16 only (--use_fp16_tensorrt)?

Yes, I  installed, but for some modules, I didn't follow the INSTALL.md strictly due to Jetson NX (Maybe this is the cause.).  Some modules have been installed with the JetPack4.4.1, as follows:

When I try to run without  TensorRT (--disable_tensorrt) or use FP16 only (--use_fp16_tensorrt), all things are OK but one error:
#######
$ python3 eval.py --disable_tensorrt --trained_model=./weights/yolact_edge_54_800000.pth
Config not specified. Parsed yolact_edge_config from the file name.
loading annotations into memory...
Done (t=1.35s)
creating index...
index created!
[02/01 16:59:11 yolact.eval]: Loading model...
[02/01 16:59:19 yolact.eval]: Model loaded.
Processing Images  ██████████████████████████████   4952 /   4952 (100.00%)     1.86 fps
Saving data...
[02/01 17:44:18 yolact.eval]: Calculating mAP...
[02/01 17:44:50 yolact.eval]:
|  all  |  .50  |  .55  |  .60  |  .65  |  .70  |  .75  |  .80  |  .85  |  .90  |  .95  |
-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
box | 31.92 | 51.90 | 49.68 | 46.80 | 43.39 | 39.47 | 34.08 | 27.17 | 18.04 |  7.82 |  0.85 |
mask | 29.59 | 47.78 | 45.46 | 42.78 | 39.51 | 35.57 | 31.11 | 25.21 | 17.86 |  9.06 |  1.60 |
-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
Segmentation fault (core dumped)
#######

You provided the log for --disable_tensorrt, and please confirm it is working for FP16 with --use_fp16_tensorrt. If this is the case, could you try calibrating INT8 with less images with cfg.torch2trt_max_calibration_images (e.g. set to 5).

You provided the log for --disable_tensorrt, and please confirm it is working for FP16 with --use_fp16_tensorrt. If this is the case, could you try calibrating INT8 with less images with cfg.torch2trt_max_calibration_images (e.g. set to 5).

It works after setting cfg.torch2trt_max_calibration_images to 5, no more Segmentation fault (core dumped) error. But for 10, the error occurs again, which is interesting. Anyway, it works, thanks for your patience.
For NX, I get around 13~14 fps using yolact_edge_mobilenetv2_54_800000.pth, which is incredible. However,  taking into the hardware differences between NX and Xavier, the fps is supposed to being higher, I guess. Is there any setting to achieve this? Thanks.

I took a look at this website about the NX and AGX comparison.
It seems that NX has less RAM as well as CPU/GPU cores than AGX. The former might account for your previous OOM issue on calibration with cfg.torch2trt_max_calibration_images=100 but runs fine with five-image calibration.
The latter might suggests why it has inferior FPS than what we have on paper (correct me if the observation is wrong, thanks).
Btw, how do you measure the FPS, using --benchmark or using a video?


Error Installing Bundler - Parent Directory is World Writable but not Sticky

Hi,
I received the following error when trying to install the bundler to use wpscan. Could anyone take a look and let me know what I'm doing wrong? I'm very new to all this. Thanks!
--- ERROR REPORT TEMPLATE -------------------------------------------------------

What did you do?
I ran the command /Users/jodi-ann/.rvm/rubies/ruby-2.3.1/bin/bundle install

What did you expect to happen?
I expected Bundler to...

What happened instead?
Instead, what actually happened was...

Error details
ArgumentError: parent directory is world writable but not sticky
  /Users/jodi-ann/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/tmpdir.rb:93:in `ensure in mktmpdir'
  /Users/jodi-ann/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/tmpdir.rb:95:in `mktmpdir'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/compact_index_client/lib/compact_index_client/updater.rb:29:in `update'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:64:in `update'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:55:in `update_and_parse_checksums!'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/fetcher/compact_index.rb:65:in `available?'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/fetcher/compact_index.rb:15:in `call'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/fetcher/compact_index.rb:15:in `block in compact_index_request'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/fetcher.rb:154:in `use_api'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:331:in `block in api_fetchers'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:331:in `select'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:331:in `api_fetchers'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:336:in `block in remote_specs'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/index.rb:10:in `build'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:335:in `remote_specs'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/source/rubygems.rb:82:in `specs'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/lazy_specification.rb:56:in `__materialize__'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/spec_set.rb:91:in `block in materialize'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/spec_set.rb:88:in `map!'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/spec_set.rb:88:in `materialize'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/definition.rb:140:in `specs'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/definition.rb:129:in `resolve_remotely!'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/installer.rb:195:in `resolve_if_need'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/installer.rb:70:in `run'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/installer.rb:22:in `install'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/cli/install.rb:102:in `run'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/cli.rb:175:in `install'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/thor/lib/thor.rb:359:in `dispatch'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/vendor/thor/lib/thor/base.rb:440:in `start'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/cli.rb:11:in `start'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/exe/bundle:27:in `block in <top (required)>'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/lib/bundler/friendly_errors.rb:98:in `with_friendly_errors'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/gems/bundler-1.12.4/exe/bundle:19:in `<top (required)>'
  /Users/jodi-ann/.rvm/rubies/ruby-2.3.1/bin/bundle:22:in `load'
  /Users/jodi-ann/.rvm/rubies/ruby-2.3.1/bin/bundle:22:in `<main>'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/bin/ruby_executable_hooks:15:in `eval'
  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/bin/ruby_executable_hooks:15:in `<main>'

Environment
Bundler   1.12.4
Rubygems  2.6.4
Ruby      2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]
GEM_HOME  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@wpscan
GEM_PATH  /Users/jodi-ann/.rvm/gems/ruby-2.3.1@wpscan:/Users/jodi-ann/.rvm/gems/ruby-2.3.1@global
RVM       1.27.0 (latest)
Git       2.8.1
rubygems-bundler (1.4.4)
  Bundler settings

without
Set for your local app (/Users/jodi-ann/wpscan/.bundle/config): "test"
orig_path
Set via BUNDLE_ORIG_PATH: "/Users/jodi-ann/.rvm/gems/ruby-2.3.1@wpscan/bin:/Users/jodi-ann/.rvm/gems/ruby-2.3.1@global/bin:/Users/jodi-ann/.rvm/rubies/ruby-2.3.1/bin:/Users/jodi-ann/.rvm/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
orig_gem_path
Set via BUNDLE_ORIG_GEM_PATH: "/Users/jodi-ann/.rvm/gems/ruby-2.3.1@wpscan:/Users/jodi-ann/.rvm/gems/ruby-2.3.1@global"
--- TEMPLATE END ----------------------------------------------------------------

im having the same exact issue :(

Hi, can you please share the output of bundle env. Thanks!

Here it is:
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/dependency.rb:296:in to_specs': Could not find 'bundler' (>= 0) among 19 total gem(s) (Gem::LoadError) 	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/dependency.rb:307:in to_spec'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_gem.rb:47:in gem' 	from /usr/local/bin/bundle:22:in '
Thanks!

Same problem when installing a new gem (bundle install).
Here is my bundle env.
Environment
Bundler   1.12.5
Rubygems  2.5.1
Ruby      2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
GEM_HOME  /Users/aa/.rvm/gems/ruby-2.3.0
GEM_PATH  /Users/aa/.rvm/gems/ruby-2.3.0:/Users/aa/.rvm/gems/ruby-2.3.0@global
RVM       1.27.0 (latest)
Git       2.5.4 (Apple Git-61)
rubygems-bundler (1.4.4)

....
Any help would be much appreciated.

try sudo chmod 1777 ~/.bundle

.Tried sudo chmod 1777 ~/.bundle and got the same error when trying to install it.

Having the same issue.
ran bundle install
Environment Details:

Bundler   1.12.5
Rubygems  2.5.1
Ruby      2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
GEM_HOME  /home/Brennan/.rvm/gems/ruby-2.3.1
GEM_PATH  /home/Brennan/.rvm/gems/ruby-2.3.1:/home/Brennan/.rvm/gems/ruby-2.3.1@global
RVM       1.27.0 (latest)
Git       1.9.1

Can confirm this is happening with me too.
--- ERROR REPORT TEMPLATE -------------------------------------------------------

What did you do?
I ran the command /usr/local/bin/bundle install --deployment

What did you expect to happen?
I expected Bundler to install gems

What happened instead?
Instead, what actually happened was Bundler failed

Error details
ArgumentError: parent directory is world writable but not sticky
  /usr/share/ruby/2.0/tmpdir.rb:92:in `ensure in mktmpdir'
  /usr/share/ruby/2.0/tmpdir.rb:94:in `mktmpdir'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/compact_index_client/lib/compact_index_client/updater.rb:29:in `update'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:64:in `update'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:55:in `update_and_parse_checksums!'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/fetcher/compact_index.rb:65:in `available?'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/fetcher/compact_index.rb:15:in `call'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/fetcher/compact_index.rb:15:in `block in compact_index_request'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/fetcher.rb:154:in `use_api'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:331:in `block in api_fetchers'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:331:in `select'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:331:in `api_fetchers'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:336:in `block in remote_specs'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/index.rb:10:in `build'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:335:in `remote_specs'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/source/rubygems.rb:82:in `specs'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/lazy_specification.rb:56:in `__materialize__'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/spec_set.rb:91:in `block in materialize'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/spec_set.rb:88:in `map!'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/spec_set.rb:88:in `materialize'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/definition.rb:140:in `specs'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/definition.rb:129:in `resolve_remotely!'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/installer.rb:195:in `resolve_if_need'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/installer.rb:70:in `run'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/installer.rb:22:in `install'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/cli/install.rb:102:in `run'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/cli.rb:175:in `install'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor.rb:359:in `dispatch'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/base.rb:440:in `start'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/cli.rb:11:in `start'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/exe/bundle:27:in `block in <top (required)>'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/lib/bundler/friendly_errors.rb:98:in `with_friendly_errors'
  /usr/local/share/ruby/gems/2.0/gems/bundler-1.12.5/exe/bundle:19:in `<top (required)>'
  /usr/local/bin/bundle:23:in `load'
  /usr/local/bin/bundle:23:in `<main>'

Environment
Bundler   1.12.5
Rubygems  2.0.14
Ruby      2.0.0p451 (2014-02-24 revision 45167) [x86_64-linux]
GEM_HOME  /var/app/ondeck/vendor/bundle/ruby/2.0
GEM_PATH
Git       <IP_ADDRESS>
  Bundler settings

path
Set for your local app (/var/app/ondeck/.bundle/config): "vendor/bundle"
disable_shared_gems
Set for your local app (/var/app/ondeck/.bundle/config): true
frozen
Set for your local app (/var/app/ondeck/.bundle/config): "1"
without
Set for your local app (/var/app/ondeck/.bundle/config): "test:development"
Set via BUNDLE_WITHOUT: "test:development"
orig_path
Set via BUNDLE_ORIG_PATH: "/sbin:/usr/sbin:/bin:/usr/bin"
--- TEMPLATE END ----------------------------------------------------------------

just install a older version of bundler
gem install bundler -v 1.12.3

I also experienced this bug, and it was also fixed by downgrading to 1.12.3.

@domcleal any interest in looking into this?

The error (from Ruby's temp helper) suggests there's a directory in ~/.bundle that is 0777, which may not be secure as it's missing the sticky bit.
Try resetting all cache directories to a normal set of permissions:
find ~/.bundle/cache -type d -exec chmod 0755 {} +

The advice above for 1777 isn't terrible, but this is probably preferable!  The affected directory is probably below ~/.bundle and not ~/.bundle itself, so using the find command ought to fix it.
If you're still having the problem, please gist output from find ~/.bundle -type d -exec ls -ld {} +

@domcleal
find ~/.bundle/cache -type d -exec chmod 0755 {} +
Seemed to work for me.

If there's some way to fix this inside of bundler, we should. A PR from someone who understands why this is happening would be :rocket:

I'm struggling to think why it'd be happening, my best guess is that it's either an old bug (e.g. where ~/.bundle/cache dirs were created with a bad umask) or people have run commands to open permissions to fix some other problem.
Some solutions that may help:

Add a sanity check/fix for permissions on ~/.bundle and its subdirs, ensuring they're not world writeable and resetting those permission bits if set.  This would appease mktmpdir and perhaps make ~/.bundle more secure. (Note that this would still fail for some other bug reports where ~/.bundle dirs are already owned by other users, e.g. root.)

Use an internal copy of mktmpdir without the sticky test (https://github.com/ruby/ruby/commit/bcb9e567) and restricted to ~/.bundle. Though this may slightly worsen security if ~/.bundle is world writeable.

Create a ~/.bundle/tmp or similar and verify permissions, running mktmpdir there instead.  This might just move the problem if somehow dirs are being set to 0777, but might help users with existing installations with those permissions.

Thanks so much for all the help. However, here is the new error message I am receiving after installing the earlier bundle version:
Could not find gem 'terminal-table (>= 1.6.0)' in any of the gem sources listed in your Gemfile or available on this machine.
Run bundle install to install missing gems.

@ domcleal: Here is my output from find ~/.bundle -type d -exec ls -ld {} +:
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4561-bink6f: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77585-1ybj2nc: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44830-uktyji: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44844-qe6g2f: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-737-14flwmb: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-17ceznm: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-jc88uo: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-1sq8oa1: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-wih0dm: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25750-12fwguq: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25768-5wjr59: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-126exyk: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-c23xie: Permission denied
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4406-gxpv4x: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4418-6ua5k8: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4428-rczflq: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4452-l70bm1: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4561-bink6f: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77585-1ybj2nc: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44830-uktyji: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44844-qe6g2f: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-737-14flwmb: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-17ceznm: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-jc88uo: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-1sq8oa1: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-wih0dm: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25750-12fwguq: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25768-5wjr59: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-126exyk: Operation not permitted
chmod: Unable to change file mode on /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-c23xie: Operation not permitted
Jodi-Anns-MacBook-Pro:wpscan jodi-ann$ find ~/.bundle -type d -exec ls -ld {} +
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4561-bink6f: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77585-1ybj2nc: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44830-uktyji: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44844-qe6g2f: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-737-14flwmb: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-17ceznm: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-jc88uo: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-1sq8oa1: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-wih0dm: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25750-12fwguq: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25768-5wjr59: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-126exyk: Permission denied
find: /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-c23xie: Permission denied
drwxrwxrwt    3 root      staff   102 May 21 13:52 /Users/jodi-ann/.bundle
drwxr-xr-x    3 root      staff   102 May 21 13:52 /Users/jodi-ann/.bundle/cache
drwxrwxrwx    4 root      staff   136 May 21 15:01 /Users/jodi-ann/.bundle/cache/compact_index
drwxrwxrwx   55 root      staff  1870 Jun  7 20:46 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47
drwxrwxrwx  147 root      staff  4998 May 21 13:52 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info
drwxrwxrwx    2 root      staff    68 May 21 14:51 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4406-gxpv4x
drwxrwxrwx    3 root      staff   102 May 21 14:53 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4418-6ua5k8
drwxrwxrwx    3 root      staff   102 May 21 14:56 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4428-rczflq
drwxrwxrwx    2 root      staff    68 May 21 15:00 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4452-l70bm1
drwxr-xr-x    2 jodi-ann  staff    68 May 21 15:01 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4457-18ovzn6
drwxr-xr-x    3 jodi-ann  staff   102 May 21 15:05 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4467-euztrv
drwxr-xr-x    2 jodi-ann  staff    68 May 21 15:09 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4555-1h1sqc9
drwx------    3 root      staff   102 May 21 15:10 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4561-bink6f
drwxr-xr-x    3 jodi-ann  staff   102 May 21 15:15 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-4713-6o8q7m
drwxr-xr-x    2 jodi-ann  staff    68 May 21 16:04 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77230-osy1v6
drwxr-xr-x    3 jodi-ann  staff   102 May 21 16:04 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77232-1xaw3jc
drwxr-xr-x    3 jodi-ann  staff   102 May 21 16:05 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77237-taqx4w
drwxr-xr-x    3 jodi-ann  staff   102 May 21 16:10 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77254-13fbpi0
drwxr-xr-x    3 jodi-ann  staff   102 May 21 16:14 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77367-1un91p2
drwxr-xr-x    2 jodi-ann  staff    68 May 21 16:19 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77526-11ce0ms
drwx------    3 root      staff   102 May 21 16:20 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-77585-1ybj2nc
drwxr-xr-x    3 jodi-ann  staff   102 May 21 16:24 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-80717-i0zthi
drwxr-xr-x    2 jodi-ann  staff    68 May 21 16:28 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160521-80800-1o25p7o
drwx------    2 root      staff    68 May 22 10:46 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44830-uktyji
drwx------    2 root      staff    68 May 22 10:49 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44844-qe6g2f
drwxr-xr-x    2 jodi-ann  staff    68 May 22 10:55 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44872-17u48zi
drwxr-xr-x    3 jodi-ann  staff   102 May 22 10:57 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44881-ma8l16
drwxr-xr-x    3 jodi-ann  staff   102 May 22 11:02 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-44991-1slv34d
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:05 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45116-1jmg3wb
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:07 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45125-1lbvcwm
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:14 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45214-ygm4x5
drwxr-xr-x    3 jodi-ann  staff   102 May 22 11:16 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45219-1sn0hol
drwxr-xr-x    3 jodi-ann  staff   102 May 22 11:17 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45230-1hojs5n
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:30 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45384-xvbf0l
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:39 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45895-asd9qf
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:44 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-45912-9uceif
drwxr-xr-x    2 jodi-ann  staff    68 May 22 11:54 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-504-10ruknw
drwx------    2 root      staff    68 May 22 11:57 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-737-14flwmb
drwxr-xr-x    3 jodi-ann  staff   102 May 22 09:52 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-9405-cn0bql
drwxr-xr-x    2 jodi-ann  staff    68 May 22 09:52 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160522-9405-ozqdhw
drwx------    2 root      staff    68 May 29 19:00 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-17ceznm
drwx------    3 root      staff   102 May 29 19:00 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160529-54503-jc88uo
drwx------    2 root      staff    68 Jun  7 20:44 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-1sq8oa1
drwx------    3 root      staff   102 Jun  7 20:44 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1761-wih0dm
drwxr-xr-x    3 jodi-ann  staff   102 Jun  7 20:46 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-1772-1cu8hec
drwxr-xr-x    2 jodi-ann  staff    68 Jun  7 19:49 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25745-1fpizck
drwxr-xr-x    3 jodi-ann  staff   102 Jun  7 19:49 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25745-1ky8l6b
drwx------    3 root      staff   102 Jun  7 19:50 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25750-12fwguq
drwx------    3 root      staff   102 Jun  7 19:51 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25768-5wjr59
drwx------    3 root      staff   102 Jun  7 20:12 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-126exyk
drwx------    2 root      staff    68 Jun  7 20:12 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25818-c23xie
drwxr-xr-x    3 jodi-ann  staff   102 Jun  7 20:15 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25838-j1yjo9
drwxr-xr-x    2 jodi-ann  staff    68 Jun  7 20:15 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-25838-rd3q3b
drwxr-xr-x    3 jodi-ann  staff   102 Jun  7 20:36 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-679-7fvvg7
drwxr-xr-x    2 jodi-ann  staff    68 Jun  7 20:36 /Users/jodi-ann/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/versions20160607-679-v8uaq

@JARM876 you have lots of directories owned by root in your own directory, I'd guess you've been using sudo or similar. I'd suggest running sudo chown -R jodi-ann:staff ~/.bundle to reclaim ownership and then the find/chmod again.
Regarding your table_print error, I'd suggest filing a new issue with a copy of your Gemfile and bundle env output so we don't cross-threads.

find ~/.bundle/cache -type d -exec chmod 0755 {} +

Fixed issue for me on Windows Subsystem for Linux fresh install. Thanks @domcleal

Thanks @stevensona that worked for me. Maybe should inform others using WSL because your answer was difficult to find.

@Zatara7 Any idea how to get the word out?

You could possibly add a new issue here with the solution:
https://github.com/Microsoft/BashOnWindows
I tried creating a subreddit for this but haven't had time to work on it.
https://www.reddit.com/r/winbash
On Wed, Jun 22, 2016 at 4:48 PM, Adam Stevenson<EMAIL_ADDRESS>wrote:

@Zatara7 https://github.com/Zatara7 Any idea how to get the word out?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bundler/bundler/issues/4599#issuecomment-227887385,
or mute the thread
https://github.com/notifications/unsubscribe/AE-5e-hgajTjabipICE23hmidZ6yP-8Hks5qOa27gaJpZM4IkAQO
.

Try:
chmod +t -R ~/.bundle

source: GoRails

Is this permission thing strictly necessary? It looks like it's coming from Ruby, but this wasn't happening before (downgrading correctly resolves the issue) so I'm curious why the change.
FWIW, Bash on Windows users are going to have a hard time with this. The above fix doesn't actually work, since chmod doesn't actually yet modify ACL permissions on for your Windows files (it only works in the virtual Linux partition). See Microsoft/BashOnWindows#81. At the very least, it didn't seem to work for me, since ~/.bundle points to my C:\Users\Loren.bundle directory.

It looks like it's coming from Ruby, but this wasn't happening before (downgrading correctly resolves the issue) so I'm curious why the change.

1.12.x contains a new cache of gem information which is shared across multiple processes. My fix in 1.12.4 added the call to Ruby's mktmpdir to fix concurrency and corruption issues with the cache, but mktmpdir does enforce secure permissions causing the error.  https://github.com/bundler/bundler/issues/4599#issuecomment-224221371 notes some alternatives.

Using the command fixed for me:
$ find ~/.bundle/cache -type d -exec chmod 0755 {} +
And I'm using BashOnWindows

I'm having the same issue.

(WSL on Windows 10)
Fixed using:
$ find ~/.bundle/cache -type d -exec chmod +t {} +
However, I wander what's the root cause

$ sudo chmod 755 -R ~/.rvm

@stevensona +1 and the heaven, ´find ~/.bundle/cache -type d -exec chmod 0755 {} +´ did work, thanks!

I think this is actually being caused by Microsoft/BashOnWindows#352 - the .rvm, .gem, .bundle directories are all being created world-writeable.

For those running into the file permissions issue, try fixing permissions by setting umask 022 before installing tools like rvm/rbenv/zsh/antigen/etc.:
See issue https://github.com/Microsoft/BashOnWindows/issues/352 for details.
Normally this is handled by the login process, but login isn't used by Bash on Windows. You'll have to add it directly to your ~/.bashrc, or ~/.profile.

@neurogenesis you can run bash.exe with the --login option, I changed the shortcut to the following:
C:\Windows\System32\cmd.exe /C start bash.exe ~ --login

For some reason you can't pass options directly to the command in a shortcut target so you have to go through cmd.exe to get it to work.

@pixeltrix : thx for the reply. For sure there are a few workarounds. Was just listing some additional installs that will break with the missing umask. The --login option doesn't read from /etc/passwd, so things like shell variables aren't set. I ended up adding umask and exec /bin/zsh to my ~/.bashrc.
Ideally this will be addressed further upstream so shells other than bash are first-class citizens too (invoking something like linux.exe, which bootstraps a more complete environment than just the bash shell).

james@Darkwing-duck-linux:~/school/projects/lifeflix [master|✔]$ bundle install Warning: the running version of Bundler (1.13.2) is older than the version that created the lockfile (1.14.3). We suggest you upgrade to the latest version of Bundler by running gem install bundler`.
--- ERROR REPORT TEMPLATE -------------------------------------------------------

What did you do?
I ran the command /usr/local/bin/bundle install

What did you expect to happen?
I expected Bundler to...

What happened instead?
Instead, what happened was...
Error details
ArgumentError: parent directory is world writable but not sticky
/usr/lib/ruby/2.2.0/tmpdir.rb:92:in ensure in mktmpdir'     /usr/lib/ruby/2.2.0/tmpdir.rb:94:in mktmpdir'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/compact_index_client/lib/compact_index_client/updater.rb:29:in update'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:64:in update'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/compact_index_client/lib/compact_index_client.rb:55:in update_and_parse_checksums!'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/fetcher/compact_index.rb:67:in available?'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/fetcher/compact_index.rb:15:in call'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/fetcher/compact_index.rb:15:in block in compact_index_request'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/fetcher.rb:157:in use_api'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:332:in block in api_fetchers'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:332:in select'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:332:in api_fetchers'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:337:in block in remote_specs'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/index.rb:10:in build'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:336:in remote_specs'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/source/rubygems.rb:83:in specs'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/lazy_specification.rb:61:in __materialize__'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/spec_set.rb:91:in block in materialize'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/spec_set.rb:88:in map!'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/spec_set.rb:88:in materialize'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/definition.rb:174:in specs'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/definition.rb:162:in resolve_remotely!'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/installer.rb:225:in resolve_if_need'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/installer.rb:78:in run'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/installer.rb:24:in install'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/cli/install.rb:71:in run'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/cli.rb:189:in install'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/thor/lib/thor/command.rb:27:in run'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in invoke_command'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/thor/lib/thor.rb:359:in dispatch'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/cli.rb:20:in dispatch'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/vendor/thor/lib/thor/base.rb:440:in start'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/cli.rb:11:in start'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/exe/bundle:34:in block in <top (required)>'
/var/lib/gems/2.2.0/gems/bundler-1.13.2/lib/bundler/friendly_errors.rb:100:in with_friendly_errors'     /var/lib/gems/2.2.0/gems/bundler-1.13.2/exe/bundle:26:in <top (required)>'
/usr/local/bin/bundle:23:in load'     /usr/local/bin/bundle:23:in '
Environment
Bundler   1.13.2
Rubygems  <IP_ADDRESS>
Ruby      2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu]
GEM_HOME  /var/lib/gems/2.2.0
GEM_PATH  /var/lib/gems/2.2.0:/home/james/.gem/ruby/2.2.0:/usr/share/rubygems-integration/2.2.0:/usr/share/rubygems-integration/all
Git       1.9.1
--- TEMPLATE END ----------------------------------------------------------------
Unfortunately, an unexpected error occurred, and Bundler cannot continue.
First, try this link to see if there are any existing issue reports for this error:
https://github.com/bundler/bundler/search?q=parent+directory+is+world+writable+but+not+sticky&type=Issues
If there aren't any reports for this error yet, please create copy and paste the report template above into a new issue. Don't forget to anonymize any private data! The new issue form is located at:
https://github.com/bundler/bundler/issues/new
james@Darkwing-duck-linux:~/school/projects/lifeflix [master|✔]$ `

I saw several fixes for Windows but I run linux mint. I haven't found any commands in here that work for me yet.

I'm closing this issue, if anyone is experiencing this issue - please open a new issue with the details of your problem.


Add a new containers property to the workflow resources

What Would You Like to See Added?
Introduce a new containers property to the workflow's resources.
Why Is This Needed?
Currently, both shell and script processes are expected to run within the workflow's environment or platform, which can vary significantly from one runtime to another.
For example:

One runtime might execute a single container per workflow, utilizing embedded processors for each defined task.
Another runtime might opt to run each task in a different container.

This flexibility is crucial, as we should not impose constraints on any runtime, especially regarding their architectural choices. The diversity in implementations for shell and script tasks can lead to undesired side effects or even total incompatibility. Consider the following scenarios:

Shell scripts running in Windows versus Linux environments.
Python scripts executed in Python 2 versus Python 3.

One potential solution is to "jail" these tasks by requiring authors to specify a specific environment for each. While this approach is acceptable, it introduces new challenges, such as limiting the ability to run multiple commands or scripts successively within the same container—similar to the capabilities offered by GitHub Actions. Achieving functionality akin to GitHub Actions would necessitate significant and perhaps unnecessary refactoring of the domain-specific language (DSL).
Proposed Solution
I propose allowing authors to define top-level, reusable containers that can be assigned to script and shell tasks. This approach would:

"Jail" the environment of these tasks.
Enhance reusability, minimizing performance and cost impacts for most use cases.

Additionally, this proposal would address issue #874 by enabling authors to specify which versions of a script they wish to run, without being restricted to specific ones, as suggested in our weekly discussions.
Example Implementation
The following YAML illustrates the proposed structure:
document:
  dsl: '1.0.0-alpha1'
  namespace: default
  name: jail-shell-and-script-tasks
  version: '0.1.0'
use:
  containers:
    alpine:
      image: alpine:latest
do:
  - greetTheWorld:
      run:
        shell:
          command: '@echo "Hello, World!"'
        on: alpine  # Using a predefined container
  - greetTheWorldASecondTimeInSameContainer:
      run:
        shell:
          command: '@echo "Hello again, World!"'
        on: alpine  # Using the same predefined container as before
  - greetTheWorldUsingPython:
      run:
        script:
          code: >
            print('Hello, World!')
        on:
          image: python:3.10  # Using a container defined in-line

Conclusion
With this proposal, script and shell tasks would effectively become shorthand for container tasks and could potentially be transformed into cataloged custom functions. This change would lead to a more consistent and flexible approach for executing tasks within workflows.

@JBBianchi @ricardozanini @fjtirado @matthias-pichler What do you guys think?

If I'm correct, have we discussed this possibility in a meeting or thread? That being said, I give +1 to this proposal.
Additionally, we can add that a runtime can have a container definition by default if none is defined. The recommendation is that runtimes make the default versions and architecture clear in their documentation.

I think I am old guy and I prefer to call an embedded script within the memory adress space of the process running the workflow definition (Im also pragmatical, there are lot of libraries to run embedded javascript and python in most languages)
One of the problems I foresee with container is that, if there is a lot of script calls, the performance cost will be prohibitive. And there also implications about shared memory (which wont be available when running the scrips in an external container)
I do not think we really have to made the choice between embedded or "external" execution (for scripts, for shell the invocation has to be external to the process running the workflow). I propose the user to make the choice. If there is not on after the script, we can assume is executed embedded.
The problem of the script language version I think is manageable; we can enforce a minimum version of the script to be implemented by the runtime (so users that want to use a newer version or a different script language, use the container approach)

Enhance reusability, minimizing performance and cost impacts for most use cases.

@cdavernas so you are proposing that these scripts are also executed on the same container instance? Or just the same image?
I am just thinking that if a frequently run workflow that runs a script step in a container, then waits a week and then wants to reuse the same container instance would make it very cumbersome/expensive to keep so many container snapshots around.

embedded script within the memory adress space of the process running the workflow definition
@fjtirado how would you in this case prevent a user script from reading restricted env vars or fetching from local IPs? Examples:

if you have an event store to store workflow state, a script could read the database credentials from the env vars
if running on Amazon EC2 the script could obtain credentials from the Instance Metadata Service (IMDS at <IP_ADDRESS>) and access cloud resources. similar for other hyperscalers

I think ultimately the workflow DSL offers a way to describe control (i.e. task) flow as well as data flow. I would abstain from introducing another "out of band" data flow via e.g. files or shared memory. This would severely limit how a runtime could be implemented and make stateless implementations basically impossible. In my opinion tasks should only communicate via input output defined in the DSL. This would allow to make implementations stateless and isolated, which is super important for multi tenant implementations.

@cdavernas so you are proposing that these scripts are also executed on the same container instance? Or just the same image?

I was thinking of the container, but you raise a valid point, though it is IMHO rather related to the runtime implementation than to the DSL (how long should containers be "kept" alive and whatnot).
Allowing reusing containers, however, enables complex flows that could be performed in a non-sequential way (ex: git clone, do something unrelated such as consuming an event, git checkout without having to restart a whole container, ...), and would also mitigate the (rightful) concern of @fjtirado concerning performance cost.
Maybe we ought to think of additional properties to address your concern? Such as TTL or whatever?

I think ultimately the workflow DSL offers a way to describe control (i.e. task) flow as well as data flow. I would abstain from introducing another "out of band" data flow via e.g. files or shared memory. This would severely limit how a runtime could be implemented and make stateless implementations basically impossible. In my opinion tasks should only communicate via input output defined in the DSL. This would allow to make implementations stateless and isolated, which is super important for multi tenant implementations.

@matthias-pichler I totally agree with you!
@fjtirado as seductive as it may sound, the idea of in process/embedded shell/script processes would, at best, break portability/cross-compatibility of workflows, which is IMHO enough to dismiss it altogether.

@cdavernas
I think the GitHub actions comparison is a good starting point:
GitHub actions is specifically tailored for CI/CD where repositories need to be checked out and thus a lot of file system access has to happen. They offer to write multi step workflows even offering reusable components. But ultimately all "steps" run on the same (container) instance. Another such example is the Common Workflow Language (aka CWL). It is more targeted towards Life Sciences handling big data: Inputs and Outputs are mostly handled as files and workflows are supposed to run in one long running process.
In the middleground there are things like GitLab CI: every "job" (aka "step") runs in it's own container. So the "build" job would run before the "test" job but in completely separate containers and both would need to checkout the repository (yes it is slower than GH Actions). The "build" job would need to specify artifacts that are passed to downstream jobs. Another similar thing would be Dagster that write intermediate results to S3 and passes them between jobs. And each job has to load and write back to S3.
And then lastly there are more the application level workflow engines, e.g. AWS StepFunctions. Every step is completely stateless and independent from each other. For performance tasks that need the same files would have to be combined into one "longer" running task. Data flow only happens through the input & output of states.
Other things in this category are Netflix Conductor, Uber Cadence and things like Pipedream or Temporal because they all have the concept of workers & dispatchers/orchestrators. I would call this category the "General Purpose" workflow engines while the others are "special purpose". And I see Serverless workflows firmly in this category and thus don't think achieving CI/CD specific performance for CI/CD tasks as a main design goal when one needs to specifically design for this.

I think the GitHub actions comparison is a good starting point:

It is an AWESOME, near perfect comparison indeed. And you are perfectly right: while the idea of reusing a container sounds appealing, it does go against the concept of atomicity and statelessness. Plus, it would, as you pointed out previously, raise multiple infrastructural concerns.
As a matter of consequence, I propose we proceed with "reusable" container configuration (image, env, ...) and forget about "reusable" containers.

On a side note, you raise a very interesting point when speaking about artificats. We had a long conversation with @JBBianchi about it last week, which was concluded by the following observations:

we need to get rid of the volumes property that is currently associated with the container process, as volumes cannot be implemented in a consistent ways accross DSL runtimes and platforms (Docker vs Kubernetes)
we need a concept similar to the one of artifacts, so that authors are able to "share/access" files between tasks
we need a concept/quality of life feature thats allows tasks to access those artifacts, which would allow authors to avoid having to do potentially catastrophically costly operations such as passing around base64 buffers (see https://github.com/serverlessworkflow/specification/tree/main/use-cases/automated-data-backup)

On another note: I think we could also utilize use.containers to build a container
document:
  dsl: '1.0.0-alpha1'
  namespace: default
  name: jail-shell-and-script-tasks
  version: '0.1.0'
use:
  containers:
    alpine:
      image: alpine:latest
    node:
      build:
        dockerfile: https://github.com/nodejs/docker-node/blob/0c0069246367ac5ac0fc6bca141fb04faaca2f4b/22/bookworm/Dockerfile

the content of [build] would be inspired by the build property in docker-compose

On another note: I think we could also utilize use.containers to build a container

@matthias-pichler Thank you for the suggestion! I have some concerns about the idea, mainly because this property would only be relevant for a local Docker installation. In a remote environment, or on Kubernetes, simply building the image wouldn't be enough — we'd also need to push it to a registry, which would require additional configuration and possibly authentication.
Moreover, the feature you're proposing can already be handled quite easily using a shell script or similar approach.

I do not think running multi platform languages like python or js in embedded mode will break portability

The following script will only work on Unix like systems. I someone runs the runtime on a windows machine it will fail even though python is a "portable" language
import os

os_info = os.uname()

allowing to specify image: ubuntu:latest would make it work everywhere regardless of host operating system

if the same container is reused

well we could update the specification to say that the container will no be reused, which is what I am proposing. More concretely we should decide what the behavior of the following is
document: {}
do:
  - jsWrite:
      run:
        script:
          language: js
          code: |
            const fs = require('node:fs');
            const path = require('node:path');

            fs.writeFileSync(path.join(__dirname, 'file.txt'), 'Hello, world!');
  - jsRead:
      run:
        script:
          language: js
          code: |
            const fs = require('node:fs');
            const path = require('node:path');

            const content = fs.readFileSync(path.join(__dirname, 'file.txt'), 'utf8');
            console.log(content);
  - pythonRead:
      run:
        script:
          language: python
          code: |
            with open('file.txt', 'r') as f:
                content = f.read()
                print(content)

do we say:

both reads will always fail because state is not preserved (what I recommend, because it is the most secure & scalable and offers less ways to write weird dual-data-flow workflows)
say both reads MUST succeed, effectively forcing that a workflow MUST be executed on one instance and cannot be distributed
Leave it undefined reducing portability

On summary, I do not see any problem with the container proposal, but I do feel it can live together with embedded support for popular scripting languages like python and js.

I don't like embedded support because it exposes such a big security problem
document: {}
do:
  - imds: # gets credentials from the EC2 instance metadata service
      run:
        script:
          language: python
          code: |
            import requests

            response = requests.get("http://<IP_ADDRESS>/latest/meta-data/iam/security-credentials/")
  - env: # leaks host secrets in a Lambda function
      run:
        script:
          language: js
          code: |
            console.log(process.env.AWS_SECRET_ACCESS_KEY)
  - container: # breaks out of the container
      run:
        script:
          language: python
          code: |
            import socket

            # Connect to the Docker socket
            sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
            sock.connect("/var/run/docker.sock")

            # Send a request to list containers
            request = b"{\"method\": \"ContainerList\", \"id\": 1}\n"
            sock.sendall(request)

I think two irreconcialible schoold of thought are collisioning here ;)
I come from old 8 bit times and for me using a different container for every script invocation is like using a nuclear bomb to kill three soldied armed with arrows.
But conceptually you are right.

Maybe haha. But I think security is job 0 and we should consider this when running author provided code, especially in multi tenant environments. Isolated container instances are one way but I also know of some platforms (e.g Atlassian, Treality, ...) that compiled JS & Python provided by users to WebAssembly which also offers very high security boundaries


OuputCapture.compare() doesn't support StringComparison

It seems to me that OutputCapture.compare() doesn't support StringComparison:
Traceback (most recent call last):
  File "...", line 251, in test_...
    output.compare(
  File ".../lib/python3.8/site-packages/testfixtures/outputcapture.py", line 127, in compare
    _expected = _expected.strip()
AttributeError: 'StringComparison' object has no attribute 'strip'

This is a bit of an edge case, you can do one of two things:

compare(output.captured, expected=S(...)
pass strip_whitespace=False to the OutputCapture constructor.


fix(openapi-parser): update uri types to be uri-reference in schema v3.1

According to the OpenAPI 3.1 spec (link),

Unless specified otherwise, all properties that are URLs MAY be relative references as defined by RFC3986. Unless specified otherwise, relative references are resolved using the URLs defined in the Server Object as a Base URL. Note that these themselves MAY be relative to the referring document.

It seems the v3.0 spec already uses uri-reference. This PR updates v3.1 to use the same

Thanks for the PR! Does this work with variables?

@hanspagel do you mean server variables? I would imagine you aren't allowed to place server variables in the relative urls, only in the servers field

@coderabbit review


LazyLoadTransformer now can handle existing placeholders

Adds a new method LazyLoadTransformer.collectExistingPlaceholders which
should be used instead of convertImagesToPlaceholders if the
placeholders have been created server-side.
The new method convertImagesToPlaceholders looks for elements with the placeholder class.
No need to call convertImagesToPlaceholders.
Bug: https://phabricator.wikimedia.org/T198668

Sorry, the commit message in the first commit is wrong. Let me know if you want me to resubmit a new PR instead.

Published as NPM package v6.1.1. Please update your integration to reference this version (and don't forget to unlink).

Updated the Gerrit patch to use the published version of page lib: https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/445073/5..6


RenderTexture#destroy destroys the depth texture as well.

#6556

Maybe it would be better to move it to dispose(). Technically its the same thing for Framebuffer,  because its never recovering.. hm...

@ivanpopelyshev Dispose just removes the framebuffer from the GPU. Destroy will destroy the data itself.
We shouldn't move this to dispose. Framebuffer#dispose disposes the depth texture already by disposing the framebuffer-object, which holds the depth texture on the GPU.

We shouldn't move this to dispose. Framebuffer#dispose disposes the depth texture already by disposing the framebuffer-object, which holds the depth texture on the GPU.

Nope, that's the point - depthTexture is not disposed on the GPU automatically. Framebuffer disposes itself and renderbuffer if mounted, but not depthTexture.
            gl.deleteFramebuffer(fbo.framebuffer);
            if (fbo.stencil)
            {
                gl.deleteRenderbuffer(fbo.stencil);
            }

Oh, I feel that we are missing MSAA case here: fboFramebuffer should be also disposed automatically :(

@ivanpopelyshev Correct, because the depth texture was not added internally by the framebuffer system. This is way you cannot run gl.deleteTexture on the depth-texture - this is equivalent of destroying (not disposing) the depth texture: https://github.com/pixijs/pixi.js/blob/9cdb526a9bfbc4643d36a106be3f2b16981e516d/packages/core/src/textures/TextureSystem.ts#L353

The user might not want to destroy the depth texture and may reuse it after destroying the framebuffer. That is not the case for the stencil renderbuffer, because it is never manually added to the framebuffer.

Agree. But then it might be user problem to destroy the depth texture when he destroys renderTexture and we dont need this PR.
I don't think it matters, we can change it later, lets merge this one.

@ivanpopelyshev Agreed, it is all semantics. Putting it in render-texture makes more sense for now, as it is a higher-level API and users might face problems like with 6556.
The user can still "snatch" the depth texture before it gets destroyed by listening to "dispose".

@bigtimebuddy Done!

Did you forget to commit RenderTexture? Error: Cannot find module './RenderTexture'

@bigtimebuddy Yup, I forgot a git add .


vhost-user: preserve master req handler's result

HandlerResult is mapped to either 0 or 1 in send_ack_message() and the
actual result (e.g. fs_slave_io()'s I/O count or error number) is lost
when sending result back to slave. And slave doesn't know how much data
has been read/written nor the real error.
Fix it by perserving the real result and send it back to slave in
send_ack_message().
Fixes: #15
Signed-off-by: Eryu Guan<EMAIL_ADDRESS>

cc @liubogithub

LGTM


Filtering by max quality

Hi
I have a question about the filtering by high max quality. Is a little confusing for me. When I perform the alignment, I set the T parameter in 20, as you gave that example in the man page to "preferring higher quality mappings" in the output. Again, in the ouput I have a list of the hits (60-0) in the max quality column. I should filter here? I mean, choose only hits with MaxQual=60? 50? 40? What's the thereshold? What do you recommend? Or the necessary filtering was already done in the command line with "T = 20"?

Hi @gundizalv - it's definitely misleading the way I worded that, I will go back through and update some of the examples to remove some words that have double meaning.  The T parameter refers to the alignment threshold value, e.g. the minimum score necessary to consider a sequence aligned or not.  Increasing this value from the default increases the required similarity between the query and the reference to be considered aligned.
The mapping quality value (from the max/mean columns) instead comes from the MAPQ field in the SAM file.  This is the mapping quality that can be interpreted as the confidence value (using the phred scale) that a mapping is "correct" or not.  It takes into account the length of the match and how close to the next suboptimal match the hit is.  Shorter matches, or ones that have a very close suboptimal hit, are going to having lower qualities since there's a higher chance that the match happened by random.  Longer matches or ones without a close suboptimal hit will have higher qualities.
The alignment score (the one that's filtered by your -T parameter) doesn't necessarily mean high mapping quality (MAPQ).  You could have a really high alignment score because of a perfect match, but have a very low mapping quality if there was also a suboptimal match that did really well too.
In general, you want to filter your results by the maximum mapping quality seen for that protein (from the max quality column).  This goes under the assumption that if PALADIN aligns at least 1 read/part of a protein at really high confidence, that it's truly there, and we can consider all the other lower quality hits to the same protein as true as well.  We tend to use 20 as a value to filter by, depending on how sure we want to be, and not really touch the "-T" value (unless we're doing something special/parameter sweeps).  Let me know if that helps, I'll clear up that documentation too.

Ok. Suppouse I put "-T 20" in the command line. Now I'll have as output a .tsv file. When I check the Quality(Max) column I dont touch anything (no sort column, no delete <60 values, etc.) and accept all hits as real counts?

Regardless of which T value you use (20, default, anything else), you should generally still filter your TSV results by the max quality column.  At bare minimum, don't include anything with quality of 0, but you'll probably want to go a little higher, like 10-20.  So delete any rows that have a max quality below 20.  Just a side note, the "-T 20" has nothing to do with the 20 in the mapping quality.  One is the alignment score threshold, one is the mapping quality.  The fact that they're both 20 (from my example on the webpage and what we normally filter for in the mapping quality) is just a coincidence.

Ok, I was going to sent a paper and I wanted to be sure. Thank you very much!


Robot vacuum adds: switch voice, locate, paused and docking status and attributes clean area, clean time, clean record and status original

Robot vacuum adds: switch voice, locate, paused and docking status and attributes clean area, clean time, clean record and status original

@tsutsuku Can you review it for me? Thanks

@dougiteixeira Can you provide your robot vacuum device specifications? Some DPs in your PR are not like the documentation provided.

@tsutsuku device id: ebced93a821db35059xhsx

@dougiteixeira Can you provide your robot vacuum device specifications? Some DPs in your PR are not like the documentation provided.

@tsutsuku API response:
{
   "result": {
    "active_time":<PHONE_NUMBER>,
    "biz_type": 0,
    "category": "sd",
    "create_time":<PHONE_NUMBER>,
    "icon": "smart/icon/ay1567915509987ktVbv/1e7c3bc6db8248416a8d99db689aa689.png",
    "id": "<removed>",
    "ip": "<removed>",
    "lat": "<removed>",
    "local_key": "<removed>",
    "lon": "<removed>",
    "model": "XR011R-0006",
    "name": "Robô Aspirador",
    "online": true,
    "owner_id": "39625796",
    "product_id": "qj62eqcp4c6fdypo",
    "product_name": "Robotic Vacuum Cleaner",
    "status": [
      {
        "code": "power",
        "value": true
      },
      {
        "code": "fault",
        "value": 0
      },
      {
        "code": "electricity_left",
        "value": 100
      },
      {
        "code": "power_go",
        "value": false
      },
      {
        "code": "direction_control",
        "value": "foward"
      },
      {
        "code": "mode",
        "value": "standby"
      },
      {
        "code": "status",
        "value": "chargecompleted"
      },
      {
        "code": "suction",
        "value": "normal"
      },
      {
        "code": "voice_switch",
        "value": false
      },
      {
        "code": "clean_area",
        "value": 42
      },
      {
        "code": "clean_time",
        "value": 46
      },
      {
        "code": "clean_record",
        "value": "04604200265"
      }
    ],
    "sub": false,
    "time_zone": "-03:00",
    "uid": "<removed>",
    "update_time":<PHONE_NUMBER>,
    "uuid": "<removed>"
  },
  "success": true,
  "t":<PHONE_NUMBER>321
}

Thanks!

I've tested these changes with my vacuum and they're amazing, thanks a lot!


udisks2: fix conf file loading warnings

Description of changes
libblockdev has changed its default configuration folder location since 3.0.1.
DEFAULT_CONF_DIR_PATH
#define DEFAULT_CONF_DIR_PATH "/etc/libblockdev/<EMAIL_ADDRESS>
Or use a patch?
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Fixed #243944
Closed #43989

Ideally we should passthru libblockdev from udisks2 to avoid potential version mismatch in case a custom udisks2 package is in use.

Ideally we should passthru libblockdev from udisks2 to avoid potential version mismatch in case a custom udisks2 package is in use.

I haven't looked into how to implement this, getting it directly from the buildInputs list?

A potential implementation looks like:
diff --git a/nixos/modules/services/hardware/udisks2.nix b/nixos/modules/services/hardware/udisks2.nix
index c53dbf477742..d96f3de8b166 100644
--- a/nixos/modules/services/hardware/udisks2.nix
+++ b/nixos/modules/services/hardware/udisks2.nix
@@ -71,12 +71,15 @@ in

     environment.systemPackages = [ pkgs.udisks2 ];

-    environment.etc = (mapAttrs' (name: value: nameValuePair "udisks2/${name}" { source = value; } ) configFiles) // {
-      # We need to make sure /etc/libblockdev/conf.d is populated to avoid
+    environment.etc = (mapAttrs' (name: value: nameValuePair "udisks2/${name}" { source = value; } ) configFiles) // (
+    let
+      majorVer = versions.major pkgs.udisks2.libblockdev.version;
+    in {
+      # We need to make sure /etc/libblockdev/<EMAIL_ADDRESS>is populated to avoid
       # warnings
-      "libblockdev/conf.d/00-default.cfg".source = "${pkgs.libblockdev}/etc/libblockdev/conf.d/00-default.cfg";
-      "libblockdev/conf.d/10-lvm-dbus.cfg".source = "${pkgs.libblockdev}/etc/libblockdev/conf.d/10-lvm-dbus.cfg";
-    };
+      "libblockdev/${majorVer}/conf.d/00-default.cfg".source = "${pkgs.udisks2.libblockdev}/etc/libblockdev/${majorVer}/conf.d/00-default.cfg";
+      "libblockdev/${majorVer}/conf.d/10-lvm-dbus.cfg".source = "${pkgs.udisks2.libblockdev}/etc/libblockdev/${majorVer}/conf.d/10-lvm-dbus.cfg";
+    });

     security.polkit.enable = true;

diff --git a/pkgs/os-specific/linux/udisks/2-default.nix b/pkgs/os-specific/linux/udisks/2-default.nix
index 36f0963935bb..07a9ceaa5173 100644
--- a/pkgs/os-specific/linux/udisks/2-default.nix
+++ b/pkgs/os-specific/linux/udisks/2-default.nix
@@ -83,7 +83,10 @@ stdenv.mkDerivation rec {

   doCheck = true;

-  passthru.tests.vm = nixosTests.udisks2;
+  passthru = {
+    inherit libblockdev;
+    tests.vm = nixosTests.udisks2;
+  };

   meta = with lib; {
     description = "A daemon, tools and libraries to access and manipulate disks, storage devices and technologies";


No default prepopulated values when enums used in JSON Schema

monaco-editor version: 0.21.0
Browser: Google Chrome Version 92.0.4515.107 (Official Build) (x86_64)
OS: macOS Big Sur version 11.4
Playground code that reproduces the issue: https://microsoft.github.io/monaco-editor/playground.html#extending-language-services-configure-json-defaults
Issue Description: When specifying a JSON property with enum, no pre-population of the default value is done as in other cases like type: string or type: object, etc.
Replicate the issue:

Go to the monaco playground: JSON defaults.

On the right side, inside the editor, remove the prepopulated properties and trigger autosuggest to see properties: p1, p2 suggested, click on say p1.

Result:
Expected:

https://www.loom.com/share/387a3b367fa64878a176061f3db8aec3

The idea is that instead of entering a value, code completion is re-triggered automatically.
That's currently not implemented in the monaco json editor. I added support withhttps://github.com/microsoft/monaco-json/commit/c7c029db8e955092b148d0d0963849665fd1be68. It will be in next month's release.