nixpkgs.tcltls doesn't seem to work

[lilyball]

Issue description

I can't see how to get the nixpkgs.tcltls package to work. It doesn't seem to be available to Tcl.

Steps to reproduce

> nix run nixpkgs.tcl nixpkgs.tcltls
bash-3.2$ tclsh
% package require tls
can't find package tls

Technical details

• system: "x86_64-darwin"
• host os: Darwin 16.7.0, macOS 10.12.6
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.0
• channels(root): "nixpkgs-18.09pre133932.ee28e35ba37"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixpkgs

[Mic92]

I am not sure how this is usually solved in nixpkgs for tcl, but the following worked for me:

$ nix-shell -p tcl -p tcltls
$ export TCLLIBPATH=/nix/store/skqyvxxs4lbka6gv28pc8avs2dg019dj-tcltls-1.6.7/lib/tls1.6.7
$ tclsh
% package require tls
1.6.7

[Mic92]

It might be possible to create a tcl build hook for that, at the moment this seems to be set manually:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/version-management/fossil/default.nix#L26

[lilyball]

I just ran into this again. It's really frustrating because it means I can't use nix-shell with a shebang to invoke tclsh with the appropriate libraries. I was really hoping to be able to do that. I guess we do need a tcl build hook.

[stale]

I marked this as stale due to inactivity. → More info

[Mic92]

Still a problem.

[NasaGeek]

I believe #122472 addresses this issue.

[agbrooks]

It would be fixed, except that the tcltls package depends on an insecure version of openssl and won't build. I'm going to put together a PR that should fix that.

[agbrooks]

#123942 should fix this; no manual TCLLIBPATH shenanigans required:

$ nix-shell -p tcl tcltls --command tclsh
% package require tls
1.7.21

[lilyball]

This partially fixes it. If I include buildInputs = [ tcl tcltls ] then tclsh at build time has access to tls. But at runtime it doesn't. If I'm building a tcl application then I assume the standard configure/build setup will handle this, but if I'm building a separate package that merely needs to be able to invoke tclsh at runtime with libraries available, this doesn't help.

Experimentally, instead of using pkgs.tcl, I can use buildEnv { name = tcl.name; paths = [ tcl tcltls ]; } and tclsh will now pick up the packages (it seems to look at ../lib from whatever path it was invoked from), but I only found this out by accident. It also seems to be completely undocumented (auto_path is not documented as containing anything related to the executable path).

I think what we're missing is a tcl.withPackages function. This could return a copy of tcl with bin/tclsh wrapped for TCLLIBPATH, or it could just use buildEnv and rely on that working (though this means symlinking tclsh to another location will break it, and it relies on undocumented behavior). Or maybe both at once (this way we aren't relying on undocumented behavior, and we also get any man pages that libraries may have).

Traditionally withPackages functions take a function and pass a set of packages to them. We don't have tcl libraries nested in a package set the way we do with other languages so we can't do that unless we want to curate a set of known packages, but that seems like a maintenance issue. So maybe we could call it e.g. withTclLibs instead. Or we could move all known tcl libraries into a tclPackages set.

[NasaGeek]

I don't have any particularly helpful feedback other than a note that I believe the ../lib lookup behavior is actually documented here (in the section titled SYSTEM SPECIFIC PATHS).

[stale]

I marked this as stale due to inactivity. → More info