Directory-specific installation of packages?
79 views
Skip to first unread message
James Geddes
Jul 22, 2019, 9:05:12 AM7/22/19
to Racket Users
Dear All,
For reasons (explained below, possibly foolish reasons) I am trying to do the following:
1. Have `raco pkg install` install a package X to a specific directory, including, in the same directory, all of the dependencies of X, but excluding those dependencies that are already present in the current installation's collections; and
2. Have `raco exe myprok.rkt` look in that custom directory for `(require X)`?
I tried the `--scope-dir` option to `raco pkg install` but that installed what looks like the entire racket standard library (see below).
Many thanks,
James
PS. What I'm /really/ trying to do is distribute a little command-line programme that I wrote in Racket to my colleagues using the homebrew package manager. My programme depends on the gregor library.
Most of my colleagues don't have Racket. Homebrew likes to compile from source, so I will need to have homebrew download the dependencies I need for compilation. But now, homebrew really doesn't like you to write outside a very small set of directories during the installation process, and those don't appear to include the standard Racket collections directories.
(I could well have misunderstood this. I don't understand at all how homebrew interacts with language-specific package managers like raco, pip, cabal, and so on. My sense is that the non-raco ones install dependencies in project-specific directories and I suspect homebrew has specific support for Python libraries.)
Anyway, my program depends on the gregor library, so I tried this:
$ raco pkg install --scope-dir tmp gregor-lib
$ ls tmp
2d-lib pict-doc
at-exp-lib pict-lib
base pict-snip-lib
cext-lib pkgs.rktd
class-iop-lib plai-lib
cldr-bcp47 planet-doc
:
[ ~100 rows omitted]
:
net-doc web-server-doc
net-lib web-server-lib
option-contract-lib wxme-lib
parser-tools-doc xrepl
parser-tools-lib xrepl-doc
pconvert-lib xrepl-lib
pict zo-lib
For reasons (explained below, possibly foolish reasons) I am trying to do the following:
1. Have `raco pkg install` install a package X to a specific directory, including, in the same directory, all of the dependencies of X, but excluding those dependencies that are already present in the current installation's collections; and
2. Have `raco exe myprok.rkt` look in that custom directory for `(require X)`?
I tried the `--scope-dir` option to `raco pkg install` but that installed what looks like the entire racket standard library (see below).
Many thanks,
James
PS. What I'm /really/ trying to do is distribute a little command-line programme that I wrote in Racket to my colleagues using the homebrew package manager. My programme depends on the gregor library.
Most of my colleagues don't have Racket. Homebrew likes to compile from source, so I will need to have homebrew download the dependencies I need for compilation. But now, homebrew really doesn't like you to write outside a very small set of directories during the installation process, and those don't appear to include the standard Racket collections directories.
(I could well have misunderstood this. I don't understand at all how homebrew interacts with language-specific package managers like raco, pip, cabal, and so on. My sense is that the non-raco ones install dependencies in project-specific directories and I suspect homebrew has specific support for Python libraries.)
Anyway, my program depends on the gregor library, so I tried this:
$ raco pkg install --scope-dir tmp gregor-lib
$ ls tmp
2d-lib pict-doc
at-exp-lib pict-lib
base pict-snip-lib
cext-lib pkgs.rktd
class-iop-lib plai-lib
cldr-bcp47 planet-doc
:
[ ~100 rows omitted]
:
net-doc web-server-doc
net-lib web-server-lib
option-contract-lib wxme-lib
parser-tools-doc xrepl
parser-tools-lib xrepl-doc
pconvert-lib xrepl-lib
pict zo-lib
Stephen De Gabrielle
Jul 23, 2019, 3:17:42 AM7/23/19
to James Geddes, Racket Users
Hi James
Did you have any luck with using homebrew to package and distribute your Racket program?
I thought Bottles might be the way to go but I’m not sure: https://docs.brew.sh/Bottles
I have two ideas
a) add installing racket from homebrew to a bash script that launches your prog
b) using the create executable function in DrRacket (or raco) to build a stand-alone version that can be modified to distribute via homebrew
Kind regards
Stephen
PS I think this is a great idea that I’m sure others will use.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2C6D9102-2F63-4A0E-A033-C7FECC5F9CF8%40gmail.com.
----
Tom Gillespie
Jul 23, 2019, 3:44:06 AM7/23/19
to Stephen De Gabrielle, James Geddes, Racket Users
I have periodically investigated installing racket packages via gentoo in a dev-racket/package way that matches how python packages are installed (a far saner experience than any of python's native packaging tools). I always hit roadblocks because raco wants to hit an sqlite database that is outside the build sandbox. I usually attempt to do this via raco, but perhaps there are other ways, which might apply in this case as well. If your colleagues just need the compiled program and do not need the underlying code, why not use raco exe and distribute the standalone binary? Best,
Tom
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-%2BqQLRNVf3_EntEsyS8uYofgHo3DMz_%2B0WdFMuN7uk0cw%40mail.gmail.com.
James Geddes
Jul 28, 2019, 3:48:24 AM7/28/19
to Tom Gillespie, Stephen De Gabrielle, Racket Users
Tom, Stephen,
Many thanks for the advice.
In the end, I gave up on a single homebrew-able install. I could not find a way to have homebrew manage an app I created in Racket. During the homebrew-controlled installation process, Racket’s package manager tries to download other Racket packages; and that fails because, as Tom noted, Racket’s package manger needs to write to somewhere that homebrew won’t let it.
Stephen, I think bottles are indeed the way to go — but homebrew will only make a bottle if you can in principle compile from source. I initially tried a version of your other suggestion: I made a distributable executable and then lied to homebrew and told it this was “source code”. But I felt bad about it!
My workaround is to tell my colleagues to use homebrew to install Racket; then use `raco pkg` to install the app; and to specify `(define racket-launcher-names …)` in the info.rkt file to make an executable.
It’s a workaround because it requires an additional step beyond this: the default location for such executables is not typically in one’s PATH, so my users have to set the PATH. For most of them that’s fine, but for some it’s not great.
In general, I now have the sense that there are OS-specific package managers, and there are language-specific package managers, and they do not play nicely with each other.
Racket has such a great cross-platform story; it would be nice to have a good “distribute your own apps” story.
(On the question of uptake of different languages, I wonder whether part of Excel’s appeal might be that it supports a model in which technically sophisticated “spreadsheet developers" can make spreadsheets for “spreadsheet users”, and then distribution is straightforward; and this is a space that most programming languages have not yet colonised.)
Many thanks again,
James
Many thanks for the advice.
In the end, I gave up on a single homebrew-able install. I could not find a way to have homebrew manage an app I created in Racket. During the homebrew-controlled installation process, Racket’s package manager tries to download other Racket packages; and that fails because, as Tom noted, Racket’s package manger needs to write to somewhere that homebrew won’t let it.
Stephen, I think bottles are indeed the way to go — but homebrew will only make a bottle if you can in principle compile from source. I initially tried a version of your other suggestion: I made a distributable executable and then lied to homebrew and told it this was “source code”. But I felt bad about it!
My workaround is to tell my colleagues to use homebrew to install Racket; then use `raco pkg` to install the app; and to specify `(define racket-launcher-names …)` in the info.rkt file to make an executable.
It’s a workaround because it requires an additional step beyond this: the default location for such executables is not typically in one’s PATH, so my users have to set the PATH. For most of them that’s fine, but for some it’s not great.
In general, I now have the sense that there are OS-specific package managers, and there are language-specific package managers, and they do not play nicely with each other.
Racket has such a great cross-platform story; it would be nice to have a good “distribute your own apps” story.
(On the question of uptake of different languages, I wonder whether part of Excel’s appeal might be that it supports a model in which technically sophisticated “spreadsheet developers" can make spreadsheets for “spreadsheet users”, and then distribution is straightforward; and this is a space that most programming languages have not yet colonised.)
Many thanks again,
James
Hendrik Boom
Jul 28, 2019, 8:32:17 AM7/28/19
to Racket Users
On Sun, Jul 28, 2019 at 08:48:20AM +0100, James Geddes wrote:
>
> In general, I now have the sense that there are OS-specific package managers, and there are language-specific package managers, and they do not play nicely with each other.
This is a real problem. It's not clear what the solution needs to be.
>
> In general, I now have the sense that there are OS-specific package managers, and there are language-specific package managers, and they do not play nicely with each other.
Probably some recognition and adaptation on both sides. It's
complicated by the number of OS-dependent and language-dependent
installers.
It will probably take a number of cooperative iterations of proposals,
comments, amd try-outs with several OS's and several languages to get
any kind of consensus solution.
-- hendrik
Alex Harsanyi
Jul 28, 2019, 8:02:04 PM7/28/19
to Racket Users
On Sunday, July 28, 2019 at 3:48:24 PM UTC+8, james.geddes wrote:
My workaround is to tell my colleagues to use homebrew to install Racket; then use `raco pkg` to install the app; and to specify `(define racket-launcher-names …)` in the info.rkt file to make an executable.
It’s a workaround because it requires an additional step beyond this: the default location for such executables is not typically in one’s PATH, so my users have to set the PATH. For most of them that’s fine, but for some it’s not great.
You can always create an executable (using "raco exe") and a distribution (using "raco dist") which packs all dependencies in a single directory. The resulting executable will be stand-alone and will contain all the Racket libraries, including any external packages you use, and will run on computers that don't have Racket installed. You could even sign the resulting executable, if you have a developer certificate.
You could also provide a small shell script to update the PATH, which users will have to run once for installation (I believe MacOS stores environment variables in a plist?)
The only downside of this approach is that it does not provide a distribution mechanism. But given that you write this program for your colleagues, you could just place the program on an internal network share and tell them to fetch it from there.
Alex.
James Geddes
Jul 29, 2019, 4:19:19 AM7/29/19
to Alex Harsanyi, Racket Users
Alex, many thanks for the suggestions.
I feel I’m putting too many obstacles in the way. (On the other hand, perhaps my situation is not so unusual.) I’m trying to make something work with as few barriers as possible, both for experienced (but non-Racket!) developers, and for Mac users who are still unsure about the command-line.
> You can always create an executable (using "raco exe") and a distribution (using "raco dist") which packs all dependencies in a single directory.
This indeed was my original plan. But I worried about updates: `brew update` (or `raco pkg update`) are straightforward enough that people won’t balk. I think I can persuade people to do a one-off manual install process, but probably not repeated ones.
In fact, as a first attempt I used homebrew to distribute an executable produced by `raco dist`. But to do this one has to go against the spirit of homebrew; and it’s therefore a pain to arrange.
> You could also provide a small shell script to update the PATH, which users will have to run once for installation (I believe MacOS stores environment variables in a plist?)
In the end, I went with the “please copy this shell command into a terminal” approach to have users set the PATH. Under MacOS, at least one mechanism to set the path is to create a file under /etc/paths.d/ whose contents are the required paths, so that’s what I did. (Paths set in one's bash config aren’t picked up by Mac GUI applications, not that that matters particularly in this case.) The only downside here is that the user needs to sudo the command.
As I say, perhaps I’m just making up ad hoc objections, in which case I apologise. I’m reasonably happy with where I’ve ended up, though I remain hopeful that a more universal package manager will someday arise, perhaps along the lines of Nix (or Guix).
Many thanks again,
James
I feel I’m putting too many obstacles in the way. (On the other hand, perhaps my situation is not so unusual.) I’m trying to make something work with as few barriers as possible, both for experienced (but non-Racket!) developers, and for Mac users who are still unsure about the command-line.
> You can always create an executable (using "raco exe") and a distribution (using "raco dist") which packs all dependencies in a single directory.
In fact, as a first attempt I used homebrew to distribute an executable produced by `raco dist`. But to do this one has to go against the spirit of homebrew; and it’s therefore a pain to arrange.
> You could also provide a small shell script to update the PATH, which users will have to run once for installation (I believe MacOS stores environment variables in a plist?)
As I say, perhaps I’m just making up ad hoc objections, in which case I apologise. I’m reasonably happy with where I’ve ended up, though I remain hopeful that a more universal package manager will someday arise, perhaps along the lines of Nix (or Guix).
Many thanks again,
James
Reply all
Reply to author
Forward
0 new messages