[racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:40 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
>
> Jay McCarthy wrote on 11/30/2014 12:30 PM:
>>
>> On Sunday, November 30, 2014, Neil Van Dyke <neil at neilvandyke.org
>> <mailto:neil at neilvandyke.org>> wrote:
>>
>>
>>     Jay McCarthy wrote on 11/30/2014 12:13 PM:
>>
>>         The documentation cited is making clear that there is NO
>>         connection between the name of a package and the provided
>>         modules. There is no such thing as a package namespace.
>>
>>
>>     I'd really like there to be.  For third-party packages.
>>
>>
>> I do not know what a third party package is.
>
>
> I'm thinking of *non*-core-Racket-developers.  Who have different needs than
> core Racket developers.  It's good that Racket is blurring the distinction,
> but the needs still aren't necessarily the same.  I say "third-party" as
> shorthand familiar to me, but perhaps there's a better term.

I don't understand what you think the different needs are. I agree
that there can be a different commitment to quality from the two
groups, such as the Racket core policy for backwards compatibility
that can't be enforced on anyone else and isn't practiced by core
developers on other stuff (for instance, I don't practice this on my
experimental game libraries.) But I can't think of any other
technically different needs.

>
>>
>>
>>         Packages may find it convenient to build and provide reusable
>>         functionality with many organizational names. This is
>>         particularly true of "data", as many packages may have useful
>>         data structures.
>>
>>         Of course, as such support code becomes very useful and
>>         developed, it makes sense to sprin it off into its own package.
>>
>>
>>     Are you saying that `data` is some kind of classification of "what
>>     this module is about", and in this case specifically, "this
>>     module, which is part of some more specific package, happens to be
>>     regarding general-purpose data structures, so we're putting it
>>     over here in the `data` area of a shared namespace hierarchy"?
>>
>> Yes, although this is just for the benefit of search and reading docs; it
>> has no technical enforcement.
>>
>>     If so, I don't understand why that would be considered a good idea.
>>
>>
>> It is a principle to create general purpose reusable code in the package
>> ecosystem rather than little archipelagos with lots of private code that
>> gets duplicated and has clever names.
>
>
>
> I keep wanting to encourage lots-and-lots of packages, and they can be
> packaged and released in a very lightweight yet well-conceived manner.

Yes. The package system is optimized for this case: put a directory
online or put code inside of a github repo --- boom, you have a
package!

> To go back to your example, if it's a useful general-purpose data structures
> library, then that's another package, which should be very easy to do.  If
> the package author isn't ready to split it out, then they're not ready to
> split it out, so no sense talking about it.  As far as I can tell, in no
> case is this `data` namespace relevant.

We are not enforcing through technology either outcome of splitting it
out or not. We are are enabling the ability to split it out if they
want, however. I don't understand what "talking about it" means... do
you mean writing documentation or literally talking about by sending
emails/etc? In either case, different authors may want to do different
things and the package system doesn't enforce one decision or another.

> Side note: I really don't think ontological classification of package topics
> belongs in package names.  Topical classifications evolve over time, and
> independent of the objects themselves. Classifications belong in
> directories, not in names.

I don't understand this.

--

It sounds like there is a problem that you are searching for a
solution for and aren't finding it in what the package system
delivers. Rather than asking, "Does the package system provide
solution A?", can you ask "How does the package system solve problem
X?" That would make it much more useful for me to give a useful reply.

Jay



-- 
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