Lately, installing LWP::Simple requires the prior installation of IO::Socket::SSL, as is shown in this Travis log. However, there does not seem to be a way of forcing zef to install them in that particular order. The only way I can think of is to list it before in the depends section of META6.JSON, but that does not seem to work.
The only slightly related solution I have found is this one, but that does not provide a solution, rather reports an (old and already fixed) bug.
Also, dependencies in the different phases (build, for instance) all seem to be blended together and installed in, I guess, dependence first order.
So, other than listing IO::Socket::SSL as a dependency in LWP::Simple, or forcing installation via another direct command before, is there any other way to fix this?
The module author does not get a say towards dependency installation order. A naive solution of doing them in order would not be parallelization friendly.
As to the actual problem of the failing tests -- how is this not a bug in LWP::Simple? The tests clearly fail due to missing IO::Socket::SSL, so either IO::Socket::SSL should be added to its test-depends, or its test should be fixed to not point at a url that forwards to https (before the skip-all test for IO::Socket::SSL is done 4 lines below).
Related
I've run into a situation where I need to access a transitive dependency in a stable way. In other words, I'd like to declare a dependency whose version is "whatever library Foo is already using".
Specifically, I'm setting up an Eleventy site and want to use markdown-it-anchor with it. Both libraries involve slugifying text, for which markdown-it-anchor allows you to specify a custom function. To keep everything consistent, I want to tell markdown-it-anchor to use the same slugifying function as Eleventy. Eleventy doesn't export its slugifying function, but it's just using #sindresorhus/slugify, so I can import that directly.
The problem came in when I added a direct dependency on #sindresorhus/slugify — I added a dependency with a splat version, on the assumption that npm would simply resolve it to the version of #sindresorhus/slugify which was already present in node_modules/. Instead, it resolved to the latest version. I tried playing around with editing package.json and even package-lock.json manually, but npm is very firm about installing Eleventy's version of #sindresorhus/slugify where I can't reach it and not installing the same version for my own use unless I duplicate the version specifier in my package.json.
What I want is to be able to freely update Eleventy in the future and have reasonable confidence that markdown-it-anchor will continue to be passed the correct version of #sindresorhus/slugify without having to manually verify each time that Eleventy hasn't bumped their dependency. Is there any way to accomplish that?
Well, I kind of got this to work. I say "kind of" because I'm depending on the splat version ("*") of my transitive dependency, which is pretty fragile. Getting it to work at all was pretty ugly, too, so there are multiple ways in which this isn't a "proper" solution.
Opened up package-lock.json and looked at the transitive dependency's dependencies (and transitive dependencies). Fortunately, for #sindresorhus/slugify, this isn't too bad.
Rearranged node_modules/ to move the transitive dependency to the top level (where my package can find it), and all of it's dependencies to where it can find them, without introducing new version conflicts. Again, in my case, this wasn't too bad.
Edited both package-lock.json and node_modules/.package-lock.json to reflect the moved packages' new locations.
Ran npm ci both to verify that I hadn't made any terrible mistakes and to make sure package-lock.json and node_modules/.package-lock.json were formatted the way it liked. (The only change it made was to reorder the packages to keep their directories sorted.)
Manually added a dependency on the (now formerly) transitive dependency with a splat version.
Ran npm install and verified that it didn't actually install or rearrange anything.
After all that, #sindresorhus/slugify works as expected when used directly from my site's build. There are a couple of serious caveats, though:
I'm not sure what npm's behavior will be if/when Eleventy updates its dependency on #sindresorhus/slugify. It may well simply update the latter where it's already located, in which everything will be fine. Otherwise, it probably won't.
I'm also not sure what npm's behavior will be if/when #sindresorhus/slugify gets added as a dependency anywhere else. It may well leave the existing version where it is and install new, conflicting versions under the …/node_modules/ folder of whatever packages require them, in which case everything will be fine. Otherwise, it probably won't.
In other words, I discovered a way to put a fair amount of effort into creating a situation which seems to work, but may not actually do what I originally wanted. 😅
When comparing different RPM files, I've noticed that not all of them expose the same header tags. So there must be some logic that activates/deactivates creation of some of them.
One example is the build time and host. I've stumbled upon two RPM specs. Neither mentions anything that looks at all like a specification or switch to provide the information. Still, one of them is generated with Build Time and Build Host fields, the other isn't (I am not permitted to post either one).
I am aware of the new _buildhost macro. The RPM version used to generate both is insufficient to use it. Both packages get created from a list of Sources, as far as I can see. The one that doesn't display the build information gets built using CMake/CPack, the other uses rpmbuild directly, that's the only information I have about serious difference.
Both are defined as Group: AddOn. So far, I haven't found any remotely definite resources about what groups are valid, or their meanings. Only thing I found was the list of deprecated groups in Fedora. I'd be more interested in a list of supported ones, but wasn't successful so far.
Resources I've found until now (omitting the pointless ones):
Max RPM Package Building Page, RedHat blog-ish tutorial, The RPM build guide, The actual RPM tags documentation, The RPM packaging guide
Unfortunately, none of the above provide the information I'm looking for.
"Give a man a fish" question: How can I suppress creation of Build Time or Build Host in rpm 4.11, be it in spec syntax or in usage of rpmbuild?
"Teach a man how to fish" question: Is there any documentation about what header tags get created with which settings?
You can use Mock for building rpm (recommended anyway). and use config_opts['hostname'] = 'my.own.hostname'.
Mock will call sethostname() in the chroot.
This is the only way how to do it AFAIK.
rpmbuild should honor SOURCE_DATE_EPOCH - but I never used it.
You can set environment variable using:
config_opts['environment']['SOURCE_DATE_EPOCH'] = 'foo'
Context
I'm trying to apply some PRs to a VSCode plugin, but the original code lacks package-lock.json file and doesn't build anymore; even after applying a PR with compile fixes, the code does not work correctly. Inspecting the published plugin shows different dependency versions have been picked*, and the author of the PR suggested this might be the root problem.
*I've compared, e.g., the outputs of
$ grep '_id' server/node_modules/*/package.json in my local build, vs
$ grep '_id' ~/.vscode/extensions/siegebell.vscoq-0.2.7/server/node_modules/*/package.json on the version from the VSCode Marketplace, and they're pretty different.
Question
Is there a good way to reconstruct the correct dependency versions (and modify package.json or package-lock.json)? Or is there a better way to reproduce the original build?
Beware, I'm a developer, but not a TypeScript/JavaScript developer.
My question is meant to be somewhat general, but if you want to see details of specific issues, the original issue and PR are https://github.com/siegebell/vscoq/issues/147 https://github.com/siegebell/vscoq/pull/148.
EDIT: FWIW, I aborted my attempt and the project was resurrected by an expert, tho somebody might find themselves in similar situations.
I installed Perl6 with rakudobrew and wanded to browse the installed files to see a list of hex-filenames in ~/.rakudobrew/moar-2018.08/install/share/perl6/site/sources as well as ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/.
E.g.
> ls ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/
09A0291155A88760B69483D7F27D1FBD8A131A35 AAC61C0EC6F88780427830443A057030CAA33846
24DD121B5B4774C04A7084827BFAD92199756E03 C57EBB9F7A3922A4DA48EE8FCF34A4DC55942942
2ACCA56EF5582D3ED623105F00BD76D7449263F7 C712FE6969F786C9380D643DF17E85D06868219E
51E302443A2C8FF185ABC10CA1E5520EFEE885A1 FBA542C3C62C08EB82C1F4D25BE7B4696F41B923
522BE83A1D821D8844E8579B32BA04966BAB7B87 FE7156F9200E802D3DB8FA628CF91AD6B020539B
5DD1D8B49C838828E13504545C427D3D157E56EC
The files contain the source of packages but this does not feel very accessible. What is the rational for that?
In Perl 6, the mechanism for loading modules and caching their compilations is pluggable. Rakudo Perl 6 comes with two main mechanisms for this.
One is a file-system based repository, and it's used with things like -Ilib. This resolves modules simply using paths on disk. Whenever a module loaded, it first has to check that the modules sources have not changed in order to re-compile them if so. This is ideal for development, however such checks take time. Furthermore, this doesn't allow for having multiple versions of the same module available and picking the one matching the specification in the use statement. Again, ideal for development, when you just want it to use your latest changes, but less so for installation of modules from the ecosystem.
The other is an installation repository. Here, specific versions of modules are installed and precompiled. It is expected that all interactions with such a repository will be done through the API or tools using the API (for example, zef locate Some::Module). It's assumed that once a specific version of a module has been installed, then it is immutable. Thus, no checks need to be done against source, and it can go straight to loaded the compiled version of the module.
Thus, the installation repository is not intended for direct human consumption. The SHA-1s are primarily an implementation convenience; an alternative scheme could have been used in return for a bit more effort (and may well be used in the future). However, the SHA-1s do also create the appearance of something that wasn't intended for direct manipulation - which is indeed the case: editing a source file in there will have no effect in the immediate, and probably confusing effects next time the compiler is upgraded to a new version.
According to Ivy documentation dependency with changing="true" means the module can change even if the revision is the same. This is useful especially for integration.
Now, I expect the system is smart enough so it does not download artifacts every time.
It can compare, for example, "publication" timestamps in ivy.xml and download (and cache) only if necessary.
But this is not the case if the dependency has rev="latest.integration". I see it downloads artifacts every time and I'm sure they were not changed. If I change "rev" to some exact revision, then it works as expected.
Is this expected behavior and do I have any chance to make it work with "latest.integration"?
I use Ivy 2.2.0.
Obscure problem. Your report does appear to contradict a strict interpretation of how the changing module functionality works.
I'd suggest raising a ticket on the ivy JIRA. Not an issue that can be solved here.