@phillip I only know of https://docs.racket-lang.org/raco/exe.html?q=raco%20exe but that’s only adjacent to what you are asking.

I’m working on the package at https://git.sr.ht/~sschwarzer/todo-txt . Since it deals with a file format, I thought it would make sense to put the package into the file collection, so it can be require d with (require file/todo-txt). Does this make sense? Or should I rather use just "todo-txt" as collection?

Yes that’s a perfectly reasonable thing to do

@samth I guess this refers to the file “subcollection”?

Yes, you can see lots of packages that do this with the data collection

I’m trying to test-install my package from the above Git repo with $ raco pkg install <https://git.sr.ht/~sschwarzer/todo-txt#main> but I get Downloading checksum for todo-txt Cloning remote directory <https://git.sr.ht/~sschwarzer/todo-txt#main> raco pkg install: could not find MANIFEST for package source source: <https://git.sr.ht/~sschwarzer/todo-txt#main> possible solution: If the URL is intended to refer to a Git repository, use <https://git.sr.ht/~sschwarzer/todo-txt.git#main> so that the URL ends in ".git" On the other hand, when I do add the .git suffix as suggested, I get the error Querying Git references for todo-txt at <git://git.sr.ht/~sschwarzer/todo-txt.git#main> tcp-connect: connection failed hostname: <http://git.sr.ht\|git.sr.ht> port number: 9418 system error: Connection refused; errno=111 context...: /sd/racket/current/collects/racket/contract/private/arrow-val-first.rkt:486:18 /sd/racket/current/collects/net/git-checkout.rkt:238:0: initial-connect /sd/racket/current/collects/net/git-checkout.rkt:54:2: retry-loop /sd/racket/current/collects/pkg/private/stage.rkt:59:2: lookup-normally /sd/racket/current/collects/pkg/private/stage.rkt:107:0: stage-package/info /sd/racket/current/collects/pkg/private/install.rkt:141:0: install-packages /sd/racket/current/collects/pkg/private/install.rkt:925:4 /sd/racket/current/collects/racket/contract/private/arrow-val-first.rkt:555:3 /sd/racket/current/collects/racket/file.rkt:437:8 /sd/racket/current/collects/racket/file.rkt:426:0: call-with-file-lock /sd/racket/current/collects/pkg/main.rkt:216:16 body of (submod "/sd/racket/current/collects/pkg/main.rkt" main) /sd/racket/current/collects/raco/raco.rkt:41:0 body of "/sd/racket/current/collects/raco/raco.rkt" body of "/sd/racket/current/collects/raco/main.rkt" Now, I could add a MANIFEST file, but I suppose raco install should have accepted one of the syntaxes (with or without .git), right?

The manifest file is unlikely to work

The .git syntax ought to

Does that server support the regular git protocol?

I’m not sure how to do that though. Would I create a file subdirectory in my Git repo and move the contents there that are currently at the root of the repo, and change the collection in the info.rkt to “file”? I tried keeping the directory structure and changing the collection to “file/todo-rkt”, but that gives me a contract violation for an invalid collection value.

Yes

I got something mixed up above. I wanted to paste this as the last output: $ raco pkg install <https://git.sr.ht/~sschwarzer/todo-txt.git#main> Querying Git references for todo-txt at <https://git.sr.ht/~sschwarzer/todo-txt.git#main> pkg: Git checkout initial protocol failed; the given URL might not refer to a Git repository given URL: <https://git.sr.ht/~sschwarzer/todo-txt.git#main> context...: /sd/racket/current/collects/pkg/private/stage.rkt:762:25 /sd/racket/current/collects/net/git-checkout.rkt:336:0: parse-initial-refs /sd/racket/current/collects/net/git-checkout.rkt:73:8 /sd/racket/current/collects/net/git-checkout.rkt:54:2: retry-loop /sd/racket/current/collects/pkg/private/stage.rkt:59:2: lookup-normally /sd/racket/current/collects/pkg/private/stage.rkt:107:0: stage-package/info /sd/racket/current/collects/pkg/private/install.rkt:141:0: install-packages /sd/racket/current/collects/pkg/private/install.rkt:925:4 /sd/racket/current/collects/racket/contract/private/arrow-val-first.rkt:555:3 /sd/racket/current/collects/racket/file.rkt:437:8 /sd/racket/current/collects/racket/file.rkt:426:0: call-with-file-lock /sd/racket/current/collects/pkg/main.rkt:216:16 body of (submod "/sd/racket/current/collects/pkg/main.rkt" main) /sd/racket/current/collects/raco/raco.rkt:41:0 body of "/sd/racket/current/collects/raco/raco.rkt" body of "/sd/racket/current/collects/raco/main.rkt" I still get a traceback, but it’s a bit different.

That said, the traceback further up is when trying the git:// protocol.

I think it should. I’m confused.

Let me try a git clone with git://.

No, that doesn’t work (connection refused).

But $ git clone <https://git.sr.ht/~sschwarzer/todo-txt> todo-txt2 does work.

at command line, you need to run git clone with <mailto:git@git.sr.ht\|git@git.sr.ht>:~sschwarzer/todo-txt

Like here? https://github.com/countvajhula/lazytree/tree/master

@capfredf Yes, but I try to “simulate” how the package server would clone the repo when someone tries to install my package later with raco pkg install todo-txt.

I wonder why raco pkg install https://... doesn’t work although git clone https://... works.

This is a little weird. raco pkg install --clone <dir> you-pkg-git-url also works

But then, to test how raco pkg install would pick up my repo and use the directory layout, the git clone <mailto:git@git.sr.ht\|git@git.sr.ht>:... would work.

I am not sure if git-checkout uses git clone git@ under the hood, because the latter requires ssh authentication.

but git-checkout has no problem accessing your repo via https

&gt; (git-checkout "<http://git.sr.ht\|git.sr.ht>" "~sschwarzer/todo-txt" #:dest-dir #f #:transport 'https) Contacting <http://git.sr.ht\|git.sr.ht> Getting refs "f58e60532f0f03c7b9a8cc80fc19d5a129d76ae2"

I have the ssh key configured in .ssh/config , so it’s picked up from there and the git clone git@... would most likely not work when used “anonymously.”

> but git-checkout has no problem accessing your repo via https That’s indeed funny. (I didn’t know about (git-checkout ...) , interesting.)

raco pkg install does not use ssh or the git binary (unless you use —clone)

Alternatively, maybe you could push your package to a bitbucket repo, run pkg install with that repo’s url, and see what will happen

@capfredf Interesting idea, I’m going to try this (for additional debugging info since other workarounds seem to be more usable).

I’m currently not able to do the Bitbucket test because my account seems to be messed up (maybe due to the removal of the Mercurial support some time ago). I mailed the Bitbucket support.

Yes. Note the use of multi

The current state is here: https://git.sr.ht/~sschwarzer/todo-txt

When I’m in my local Git working directory named todo-txt and type raco pkg install ../todo-txt , I see some progress output (no exception). I had expected that I then would be able to open a racket shell and import the module with (require file/todo-txt) , but I get > (require file/todo-txt) ; open-input-file: cannot open module file ; module path: file/todo-txt ; path: /sd/racket/current/collects/file/todo-txt.rkt ; system error: no such file or directory; rkt_err=3 ; [,bt for context] The last part of the file definitely looks wrong because I expected that the module would be imported from /sd/racket/current/collects/file/todo-txt/main.rkt. Does the main.rkt “trick” not work for multi-collection packages?

But probably something else is more fundamentally wrong because I don’t see file/todo-rkt under /sd/racket/current/collects. Maybe related is that raco pkg show shows todo-txt as a linked package. How is (require file/todo-txt) supposed to find a linked package?

You definitely need a file named todo-txt.rkt

The problem is that raco pkg requires a .git suffix on a URL that is to be interpreted as a Git repository. That rule is a way to distinguish Git-repo references from remote-archive references, since the latter came first in the raco pkg implementation.

Removing that limitation will require changing the specification of package sources, maybe by recognizing a query in a URL to declares “this is meant to be a Git reference over HTTPS”.

I’m not sure how many pieces of infrastructure need to change, but at least the raco pkg client (so users would need a new enough Racket to get a package using the revised rules) and the http://pkgs.racket-lang.org\|pkgs.racket-lang.org server.

@mflatt how about we have raco pkg first interpret a URL without a .git suffix as a remote archive reference but if it fails, try the URL as a git repo reference?

Fallbacks and search paths create trouble, so I’d treat that as a last resort.