[racket-dev] new package system collections and conflicts

Your frustration is understandable given the lack of charity I've
shown in this thread. I apologize and promise to try to be better.

I know I'm repeating myself annoyingly, but I think the most
productive way to move forward is if you could identify problems that
you're trying to solve where the package system is getting in the way.
We can then work together to figure out a solution.

I suspect that the majority of the problems you see now are due to my
failure to explain the purpose of the package system and its relation
to Planet.

I hope to write a blog post in the very near future that explains the
relationship between Planet and the package system. I intend to sketch
how the latter can emulate the former in a near-perfect manner. My
hope is that this post will help explain the package system and show
that it does not prevent you from doing anything that Planet let you
do, it only allows you to do more.

I'm very sorry for my annoyed responses earlier. I'm grateful for your
contributions to the Racket ecosystem.

Love always,

Jay

On Tue, Dec 2, 2014 at 7:12 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> I think this "what's the matter with conflicts, and an arbitrary package
> putting things wherever it wants, and not having a notion of
> non-backward-compatibility" is similar to "what's the matter with using eval
> for everything" or "what's the matter with defmacro" or "what's the big deal
> about having subroutines in a language".
>
> The questioner's position works for them, some other person thinks it's a
> very bad idea, and you can trot out hypothetical scenarios and anecdotes,
> but -- since it can be argued to reduce to pragmatic tradeoffs involving
> unknowns -- you can't (at least I can't) persuade someone who thinks they
> know better.
>
> How about we just say that the module system was originally designed as
> something that core Racket developers would like to use, having a low
> friction to moving an individual core developer's side projects into the
> tidy-looking core, or to doing other kinds of shifting they would like to do
> in core Racket?  Without an acknowledgement that not all third-party package
> developers will be working like that, nor that everyone wants to make the
> substantial compromises to facilitate that low friction.
>
> For third-party developers like me, I can layer something to work around
> some of the drawbacks, and, pragmatically, that's what I'll have to do.
>
> Neil V.
>



-- 
Jay McCarthy
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33