Comments (12)
I would also be happy to help out with improving the situation but I would need some indication if this is an issue that rules_perl wants to solve.
from rules_perl.
I wonder if we make it more obvious how perls toolchains is configured and let nix people just give it a nixos attribute instead
I'm afraid I don't understand what a nixos attribute is and how it would make the perl binaries embedded in the toolchain of rules_perl hermetic.
If at all possible, I would like to avoid dependencies on system package managers like nix for my bazel project.
from rules_perl.
@malt3 - I normally review these on the weekend, however, was away from all electronics this last one.
This is one of Perl's deficits - wanting to be installed on the whole system. Openssl also surfers from this. Trying to compile these in a hermetical way would bring in most of the Linux kernel. At least that is my first impression - this is why we have Docker.
I'm open to any ideas that furthers Perl's first world status in Bazel! How would you proceed?
from rules_perl.
I think there are two ways to solve this:
- build a fully static version of perl with something like musl libc
- ship all or most of the dynamic libraries with the perl binary and make it work using runfiles in bazel
Once we have a fully static binary, using the first approach would be way simpler imo.
In any case this could be an opt-in for now (an additional toolchain that has to be selected by rules_perl users) so we don't break anyone's usage.
from rules_perl.
Hi fellow nix user!
I wonder if we make it more obvious how perls toolchains is configured and let nix people just give it a nixos attribute instead
from rules_perl.
I wonder if we make it more obvious how perls toolchains is configured and let nix people just give it a nixos attribute instead
I'm afraid I don't understand what a nixos attribute is and how it would make the perl binaries embedded in the toolchain of rules_perl hermetic. If at all possible, I would like to avoid dependencies on system package managers like nix for my bazel project.
So my statement is based on your original quote.
This makes the rules non-hermetic and prevents usage in clean environments like nixOS.
Take this reply with a dismissal if I misunderstand your original statement, I assume here you mean nixOs as in nixOs reproducible builds and deployments
If you are (like me) on NixOS you have /nix
around, I would suggest that you have the capability to be hermetic. One solution for you might be to use rules_nixpkgs to bring in a fixed known version of Perl and its runtime, which would look something like so:
# Use a fixed version of the nix tree (could also be done more in a default.nix)
nixpkgs_git_repository(
name = "nixpkgs",
revision = "22.05",
sha256 = "0f8c25433a6611fa5664797cd049c80faefec91575718794c701f3b033f2db01",
)
# Grab perl
nixpkgs_package(
name = "perl",
attribute_path = "perl536",
repositories = { "nixpkgs": "@nixpkgs//:default.nix" }
)
For what it's worth, we use this in some places at $DAYJOB to bring in complex software we still want to be known fixed versions, but we want to avoid building the entire tool chain from ground zero. Examples of our usage are shellcheck
, ffmpeg
, manim
, wine
and some very strange cryptographic prover tools, all of which do not readily exist in "just download this tarball and run" form and would be pretty hard to make work in that way.
This wouldn't be a system dep that would be fixed in time and highly hermetic, you would get a nix derivation specific to the build rather than anything you installed in home-manager
or nix-env iA perl
.
At that point, it might be possible (I have not tested) to use @perl//:bin/perl
(and similar) as the Perl interpreter
I genuinely understand if you would rather not force nix onto your consumers, but you might consider this for your environment.
- If you have control over your machines and dev env to have NixOS in your developer orbit you could encourage this, and we could see if the rules could be tweaked to cope
- If you don't, and you are solving for your local problems, it could be something that can be configuration gated in
.bazelrc
- It might be possible to pull the toolchains from a docker image like some other Bazel rules do, although that's going to require docker and be akin to the NixOS solution.
I would suggest that a full musl-libc static Perl build is possible, but might be beyond the scope of these rules and the support herein. If there is a known static build / tarball laying about, it might be possible to switch up to that.
from rules_perl.
@GregBowyer thanks for this detailed explanation. If at all possible I would like to make the Bazel workflow not depend on nix / rules_nixpkgs
, although it does seem like a very ergonomic way to bring in complex build tools.
Gating this behind a config in .bazelrc
also sounds nice. I may try this out.
Can you maybe elaborate what you mean by this sentence?
It might be possible to pull the toolchains from a docker image
This sounds like a possible workaround but I am not sure on what level this will be applied. Do you mean the docker sandbox?
I would suggest that a full musl-libc static Perl build is possible, but might be beyond the scope of these rules and the support herein. If there is a known static build / tarball laying about, it might be possible to switch up to that.
Yes this would be my preferred solution but from searching around, it seems this may not exist yet. I understand that this is beyond the scope.
from rules_perl.
Yes the docker sandbox
from rules_perl.
I think I'll support my own fork of relocatable_perl
and rules_perl
for now. I also created release artifacts that offer a statically linked perl toolchain. I only need perl to configure OpenSSL so I don't strictly need a full perl (with extensions).
If you have ideas how a statically linked toolchain could co-exist, please feel free to reach out.
from rules_perl.
@malt3 sorry this is so random but do you have a link to the way you configured openssl
with bazel
? I have been trying for several days and can't seem to get around various issues: #61. I looked through your repos and couldn't find the way you did it so it must be on a private repo.
from rules_perl.
@andrewkatson i was simply using the example from rules_foreign_cc. I since stopped doing that.
I can recommend using boringssl as a drop-in replacement instead. It comes with Bazel BUILD files out of the box and works well.
The rules_foreign_cc solution is not used by me anymore and I could not find my code from back then.
from rules_perl.
No problem! Yeah I would use it but its missing some functions that my legacy application uses. So I am going to figure out how to migrate to boringssl or finish my current non rules_foreign_cc
approach.
from rules_perl.
Related Issues (20)
- Flag --incompatible_disable_target_provider_fields will break rules_perl in Bazel 1.2.1
- Flag --incompatible_run_shell_command_string will break rules_perl in Bazel 1.2.1
- Flag --incompatible_no_implicit_file_export will break rules_perl in a future Bazel release
- C/C++ dependencies are completely ignored in "perl_xs" targets. HOT 2
- perl_binary does not work as a data dependency
- Feature Request: Windows Support (NOT IMPLEMENTED) HOT 7
- Rename master branch to main HOT 7
- Support import via http_archive HOT 2
- Tag a release HOT 2
- Feature Request: Support cpu: ppc64le
- Toolchains for linux/darwin are always downloaded via a third-party mirror
- Toolchain missing for (darwin, aarch64)
- Cut a release including bzlmod support HOT 4
- Parameter to use fallback must be a directory not a file HOT 1
- toolchain uses host's perl libs
- Use release artifacts instead of github source tarballs
- [Bazel CI] Error migrate to Bzlmod
- [Bazel CI] Error: Remove unknown repo `@fcgi` from Bazel files
- Transfer rules_perl to bazel-contrib HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rules_perl.