(Sorry for double post, forgot to respond to another point)
Regarding using semantic version to resolve correct dependencies: what do
you do when a codebase needs two different versions of a package? Suppose
your app depends on packages A and B, but both A and B depend on C. More
specifically,
I've also been working on some package server stuff, can I point you to it?
In particular there's work there that makes package catalogs first class
citizens, documenting the available routes for uploading and modifying
packages, and stuff like that. It's buried in my docker-racket-catalog
repo
I too think it would be fantastic if you took this on.
Robby
On Tuesday, September 1, 2015, Alexis King wrote:
> > Take a bigger stab. Post code. Submit pull requests.
>
> It’s on my list of Racket projects to work on! ;) My recent updates to my
> Heroku buildpack and my release of my environm
> Take a bigger stab. Post code. Submit pull requests.
It’s on my list of Racket projects to work on! ;) My recent updates to my
Heroku buildpack and my release of my environment variable manager actually
came out of working with the web server. I’m playing with it, but I haven’t
gotten very f
At Tue, 1 Sep 2015 15:58:44 -0700, Alexis King wrote:
> I’ve actually taken some small stabs at implementing something like
> this,
Great!
> but it’s a nontrivial project
That's almost certainly true.
> especially since the current
> package server’s API seems to be undocumented (I’m referrin
Alexis King wrote on 09/01/2015 06:58 PM:
First, from Neil:
My super-strongly preferred engineering notion: backward-compatibility of a
package refers to the *documented* behavior of the package, not to actual
behavior.
These are both incredibly flawed. They might work fine in a tiny little
The frustrating thing about this problem is that it is a problem that seems to
be fundamentally *solved*. PLaneT didn’t do it quite right, it’s true, but the
current package system doesn’t, either. In fact, in a number of ways, the new
system is catastrophically worse than the old one (it doesn’
Another thing that's important to what I need from the package system...
I'd like to promote a model of software development based on a mix of
many modules written from the start to be reusable. A system comprises
modules both off-the-shelf third-party and developed in-house. The
in-house mo
On Tue, Sep 1, 2015 at 6:31 PM, Jack Firth wrote:
> I agree with the points about clutter and cumbersome-ness, but I think that
> could be fixed with smarter UI and the like on the package server and
> package installation process. A simple thing to do would be to just have
> multiple packages lik
I agree with the points about clutter and cumbersome-ness, but I think that
could be fixed with smarter UI and the like on the package server and
package installation process. A simple thing to do would be to just have
multiple packages like `foo`, `foo2`, `foo3` not shown, and only the latest
I have some concerns about the "a backwards-incompatible change should
result in a new package" idea.
Firstly, it would clutter the package server. This would also confuse new
users, who would arrive at the package server and see several editions of
the same package. For just Cover we would have t
For a given package `foo`, the general idea regarding new changes that as
I've understood it is:
1. Changes to existing functionality that break things belong in a new
package `foo2` that provides differently named modules/collections from
`foo`, since it's essentially completely diffe
Personally I think it would also be helpful to encourage people to make
`unstable` collections for their packages so they know they have somewhere
to experiment with new features before committing to them fully. This is
the approach Alex and I have been using on our lens package and it's
workin
The version field in the info file can use any numbers you want under
any circumstance. It has nothing to do with the package name. It could
start at 4.x or 1.x or 99.x, whatever you want.
There is no connection between two packages with different names, no
matter if they share prefixes, suffixes,
What happens to the version in info.rkt?
Does a foo2 package have version "2.x" in info.rkt?
Or does it get reset to "1.x"? (On the theory that there's no such
thing as a backward-incompatible version of a package, just a new
package. And on the assumption a major version change implies
backward
Hi,
Meanwhile, I reduced the problematic code to a maneageable fragment.
The following code typechecks and runs fine:
#lang typed/racket
(define-type (Base-Shape R)
(U (foo-shape R)
(bar-shape R)))
(define-syntax (def-base-shape stx)
(syntax-case stx ()
[(_ (R (func-name shape-nam
16 matches
Mail list logo
