zcpkg is now in an alpha state. The server and client are operational, but the
docs are not done. I'm preparing a short demo video to show the current status
to make up for that.
https://github.com/zyrolasting/zcpkg/releases/tag/alpha
A couple of neat things are possible, but I haven't done the
At Sun, 26 Jul 2020 02:58:26 +, Sage Gerard wrote:
> You're looking for something like:
>
> (require (file "zcpkg-deps/example.com/package/module.rkt")).
Ah, got it. In my example, I wanted
(require "zcpkg-deps/mflatt/beta/b.rkt")
So, I understood the intent, but I missed "zcpkg-deps" ins
Apologies for the "PLT-sanctioned" comment. I came off
differently than intended.
> While I was able to run `zcpkg serve`, I wasn't able to set things up so that
> a request via `zcpkg -E ... install ...` downloaded from it.
> It may be because I'm unclear on how configurations work.
Your attemp
At Sat, 25 Jul 2020 21:36:20 +, Sage Gerard wrote:
> The source is at https://github.com/zyrolasting/zcpkg.
Thanks for a pointer to the implementation! Trying things out --- and,
to a lesser degree, looking at the source --- answered a lot of my
initial questions.
While I was able to run `zcp
> On Jul 25, 2020, at 5:36 PM, Sage Gerard wrote:
>
> I know this isn't a PLT-sanctioned approach, but I'd like to know if there's
> any warmth to the direction I'm headed here.
There is no such thing as “PLT-sanctioned”. If you can improve Racket, go for
it. If you can construct tools that
Reviving this thread. I spent the last couple of months on a package manager
that operates at a broader scope than `raco pkg`. It's not done because as you
all know, package managers are hard.
The source is at https://github.com/zyrolasting/zcpkg. Note that there's a
branch dedicated to using o
At Thu, 21 May 2020 15:39:30 +, Sage Gerard wrote:
> I'm not sure what improvements can be made that A) wouldn't repeat the
> problems encountered in PLaneT and B) gives users an "easy" way to deal with
> breaking changes in collection names beyond what the Package Management FAQ
> suggests.
Thanks for this, it really helps.
I'm not sure what improvements can be made that A) wouldn't repeat the problems
encountered in PLaneT and B) gives users an "easy" way to deal with breaking
changes in collection names beyond what the Package Management FAQ suggests.
I remember Sam mentioning `
FWIW:
Changing the search path for modules isn't just about changing the
`current-module-name-resolver` parameter. Paths and search rules end up
getting used in subtly different ways by different tools, such as
`racket` versus `raco setup` versus `raco exe`. The module name
resolver is more of a h
Thanks for the link. Is there a way to use the solver-based approach that's
easier than involving a tethered installation or a custom launcher? On my end
it looks like any different approach to packages would need a different module
name resolver too.
~slg
‐‐‐ Original Message ‐‐‐
On T
>
> There are basically two approaches in wide use here, depending on
> whether the underlying system was developed after this kind of package
> management approach became popular (npm, cargo, stack) or before
> (virtualenv for python and others).
>
>
`stack` (Haskell) is a bit different from `npm`
I find this discussion interesting, it caused me to search around for
links, blogposts, papers and examples about package
management. The things I found so far are accessible here (a online
collaborative text editor), but feel free to move it to some other tool,
wiki etc.:
https://cryptpad.fr/pad/
Thanks! Although I cannot really see the full implications, the basic idea
sounds really great.
DrRacket does share some things, but tries to minimize the sharing; if it
were possible to share less, that'd be great, but maybe that'll end up
falling under the same category as reasons you'd install
I'll try to write out in more detail what the kinds of package
managers Sage is referring to do, to make this clearer for everyone.
The high-level idea is that you have a bunch of directories on your
system(Alex's analogy to git is a good one), and in each of them, your
run appropriate commands an
I know this touches on a reason why PLaneT had issues, but I don't understand
how this is a problem. If two versions of the same package are in different
locations on a filesystem and the module resolver can somehow distinguish the
two using collection paths, then how else do they collide?
On Friday, May 1, 2020 at 1:02:04 PM UTC+8, Sage Gerard wrote:
>
> > The "project" would be the toplevel folder where the source files for a
> Racket application (not a package)
>
> Why can it not be a package? I would be very, very interested in finding a
> way to make this work for packages
> The "project" would be the toplevel folder where the source files for a
> Racket application (not a package)
Why can it not be a package? I would be very, very interested in finding a way
to make this work for packages as well.
Original Message
On May 1, 2020, 12:08 AM, Alex
On Friday, May 1, 2020 at 9:01:41 AM UTC+8, Robby Findler wrote:
>
> I'm trying to understand what you guys are talking about here and am not
> sure I'm getting it.
>
> Is the idea that a "project" (new term definition) would be a place one
> can install a package and its dependencies in a
I'm not familiar enough with NPM or Pipenv to fully appreciate what you're
saying, but I'm glad it sounds like I have the right basic idea. raco link
is, roughly speaking, a layer below raco pkg that is used to implement raco
pkg.
Well, at any rate, I'll be curious to see how things progress!
Rob
I'm looking for an experience similar to how NPM, Pipenv, and other package
managers work in their respective ecosystems. You described the desired
conditions correctly.
Racket's separation of packages and collections complicates that a bit. Sam
mentioned on the Slack that this problem could be
I'm trying to understand what you guys are talking about here and am not
sure I'm getting it. Is the idea that a "project" (new term definition)
would be a place one can install a package and its dependencies in a way
that avoids any conflicts with other pkgs that are already installed (even
if the
That's right: there's no one-step operation right now, and a new
one-step tool that sets things up the way you need would be a great
contribution.
To avoid anything currently in user scope, maybe your new tool would
configure the project space with a fresh 'installation-name. After
setting 'pkgs-d
Some of the pieces are falling into place, but I'm still chewing on something.
Let me rephrase my goal with added details: As a library author, I need my
users to have ONE command that safely installs a package with collection paths
that would collide in a user or (system) installation scope.
T
Consider viewing "project" scope as "installation" scope, where an
existing installation becomes a wider scope after "installation". Then,
the exiting configuration and scope machinery will match what you need.
If you take that view, then a project gets its own "etc" where you put
a "config.rktd"
Alright, so after thinking about how to improve Racket package management I
decided that I want to add project scoping logic to raco pkg install. I'm not
sure --scope-dir is enough because the docs say that the installation is
apparently checked before the scoped directories, and there are no lo
25 matches
Mail list logo
