Is there any module from /lib/modules/modules.dep that is NOT contained in /lib/modules/'uname -r' ? More precisely : if we don't pay attention to the kernel's version, can it happen ?
Related
I am working with orders and invoices.
I noticed M2 (2.4.4) removes lots of spaces in almost all variables eg. for:
order['billing_address']:
'city': 'CHAMPIGNYSURMARNE'
In backend, it's well written 'CHAMPIGNY SUR MARNE'
Idem for :
order['billing_address']
'additional_information': [
'Virementbancaire',
'Votrecommandeseraexpédiéelorsquelevirementdesonmontantseraconfirméparnotreorganismebancaire.\r\nVoustrouvereznoscoordonnéesbancairesdanslaconfirmationdecommandeenvoyéesurvotreboîteemail.'
],
I also noticed that issue doesn't happen in all variables. Even if for the time, I can only see ONE value on witch it doesn't happen :
order['status_histories']
'comment': "Remboursement de 6,00\xa0€ hors ligne. <span style='color:deeppink'>(By Axel B)</span>",
Did anyone else ever noticed this ?
My bad ! I post this answer because maybe, somebody one day could be as dizzy as me.
The reason is I use a new tool for formatting - among others - JSON and XML.
I recommend it to those who do not know it yet : DevToys (Mac an Win).
But it is responsible for my misfortunes because is't it that removes spaces when beautifying. As the file was long, I didn't even have a look a the row file. I've searched in the soft an option that could avoid this behaviour ... without success.
Is it possible to add a minimum version to a module listed in the depend section of a META6.json file?
It uses the same syntax as the Version class. You can use, for instance, v1.0+, or, in META6.json, simply "1.0+"
To declare a dependency on Foo of version 1 or higher one would do the same as if one was asking zef to install Foo:ver<1.0+>:
zef install "Foo:ver<1.0+>"
"depends" : [
"Foo:ver<1.0+>"
]
Long form identities use version literals for api and ver attributes, and strings for any other (such as auth, file, name, etc). So to describe such a dependency you should write it the same way you would if you were useing it using the literal form :foo<...> ala use Test:ver<6.d+>. This is opposed to :foo(...) form which can run anything, e.g. use Test:ver(do { say 42; v6.d+ }), which would allow arbitrary code execution by just searching for dependencies and thus is not a valid way to describe something in a META6.json
I can't find a way to correctly get access to resources of an installed distribution. For example, when a module is loaded dynamically:
require ::($module);
One way to get hold of its %?RESOURCES is to ask module to have a sub which would return this hash:
sub resources { %?RESOURCES }
But that adds extra to the boilerplate code.
Another way is to deep scan $*REPO and fetch module's distribution meta.
Are there any better options to achieve this task?
One way is to use $*REPO ( as you already mention ) along with the Distribution object that CompUnit::Repository provides as an interface to the META6 data and its mapping to a given data store / file system.
my $spec = CompUnit::DependencySpecification.new(:short-name<Zef>);
my $dist = $*REPO.resolve($spec).distribution;
say $dist.content("resources/$_").open.slurp for $dist.meta<resources>.list;
Note this only works for installed distributions at the moment, but would work for not-yet-installed distributions ( like -Ilib ) with https://github.com/rakudo/rakudo/pull/1812
I am working on REST api which has lookup by resourceid and resourceid starts with . or / or //. I am able to handle cases where it starts with / or contains / but not resources whos identifiers start with . eg: /resources/.ABC-A
Im looking some solutions on how to handle cases whose resource id starts with .
Not sure . is allowed at the start of the path. Per RFC 3896:
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names. This is similar to their role within some operating
systems' file directory structures to indicate the current directory
and parent directory, respectively. However, unlike in a file
system, these dot-segments are only interpreted within the URI path
hierarchy and are removed as part of the resolution process (Section
5.2).
Also, a word of caution when using . in your paths: by default Spring will try and use the path to determine content type:
https://spring.io/blog/2013/05/11/content-negotiation-using-spring-mvc
Example: A path ending in .au can be interpreted as a request for application/audio, for which you probably don't have a handler installed.
To disable this behavior you would set favorPathExtension=false on your ContentNegotiationConfigurer.
I have an old-style product with several classes. In the class, I have defined the meta_type and I have also registered them in __init__.py, i.e.:
def initialize(context):
context.registerClass(
ClassA.ClassA,
permission = "Add ClassA",
constructors = (ClassA.manage_addClassA,
ClassA.manage_addClassA),
icon = 'www/images/ClassA.gif'
)
This worked fine until I updated my Zope from 2.9 to 2.13. Now in the zmi, in the "Add Products" dropdown list, these meta_types are shown two times each.
I tried to track the source of this error:
ObjectManager.py, filtered_meta_types
ObjectManager.py, all_meta_types
getattr(Products, 'meta_types', ())
Now I don't know where to look next :)
It's only a nuisance, it does not cause any problems in the functionality of the product. Maybe I should update it to a new-style zope product, but I'm curious where this error comes from.
You need to remove your <five:registerPackage /> registration from the configure.zcml file, because your legacy package is using the Products. namespace.
The Products. namespace has always been auto-loaded; the initialize(context) function is implicitly being loaded for that namespace since before it was an official namespace.
When Zope started to support packages outside of the Products. namespace, however, the decision was made (wisely) to make registration explicit instead, and the <five:registerPackage /> was introduced to let you use the old registration hook if you still needed it.
In your case, however, that means your initialize() function is being called twice; once because it is a Products. package, and once because you explicitly registered it.