[Pre-RFC] Domains as namespaces


#41

I’d rather not wrap cargo builds with an additional layer of Makefiles or other scripts, because that’s exactly what this will turn into.

Take my dirs crate for instance: The original home_dir function in the standard library supported every platform Rust supports.

The replacement only supports Linux, macOS (only tested on CI), Windows (only tested on CI) and Redox (not regularly tested at all).

I’d love if people with obscure platforms were able to just drop in their own implementations for platforms I can’t support/test. This is a no-brainer if the source code is properly decoupled from the organization that provides the implementation.

My proposal does that, so having one Cargo.toml should suffice even if different platforms depend on “different” dirs crates for different platforms.

Your suggestion would make it necessary to rewrite source files during the build and probably adjust the Cargo.toml file as necessary, too. (You could do both with Makefiles for example, or whatever scripting language you fancy.)

I’d rather not go the Cargo.toml + Makefiles way, if a task can be solved with Cargo.toml alone. Popular languages picking a design is a rather good indication to avoid that design in general, if there aren’t any convincing reasons to reconsider (explanation below).


#42

You said, keep everything that exists as it is, add organization.

Crate name is unique now, which you don’t change.


#43

Do you need to verify your domain?


I’m pretty sure that this idea, if adopted, will also add a lot of lines to config.toml file. Maybe for Java world it’s ok to have huge xml configs, but I don’t want this destiny for Rust.


#44

No, because either you’re hosting a package there or you’re not. There’s no arbiter that you have to prove things to.


#45

This post was flagged by the community and is temporarily hidden.


#46

This post was flagged by the community and is temporarily hidden.


#47

I think my point was more intended to outline the user-facing changes a developer might see.

Namespaced crates would be unique in one organisation, but different organizations could of course have crates with the same name, often even intentionally.


#48

This post was flagged by the community and is temporarily hidden.


#49

This post was flagged by the community and is temporarily hidden.


#50

[Everyone, please try to raise the level of discussion here. Focus on adding new information or ideas, and asking questions about things you need clarified. Flag inappropriate or unconstructive comments rather than replying to them.]


#51

This post was flagged by the community and is temporarily hidden.


#52

@soc I’m confused, Looking up top it seems there was a lot of good discussion on the downsides of this, but I’m not sure if this has been addressed and how? This post has gotten very long with side conversations not relevant to continuing discussion for “Domains as namespaces” How do we solve the “I need to own a domain first” or “I no longer care about maintaining the domain” or “my domain was hacked” or “some one else owns my domain now” as well as anything else that was mentioned. Is there a way for you to collect the relevant arguments made in this thread and your arguments against them? Maybe post an edit to the original post and create a new post down here so people can focus on taking on the challenges of this approach?


#53

Thanks for this suggestions, I will collect the relevant points from the thread and add them to the top.


#54

Coming into this discussion as a result of the “Internals summary” email, it’s no longer clear to me what is being proposed. (I assume it was initially, but the ensuing discussion seems to have resulted in some changes?) I read A) that we’ll be adding a new capability (namespaces, which must be claimed on the basis of a URL) but not changing anything else, and B) that we’ll no longer need to worry about squatting in the existing (global) namespace, but it’s not clear to me how those two things aren’t contradictory.

Since that part of the proposal is confusing, I won’t comment.

What I will say, however, is that having some global crates and some namespaced crates is far from an ideal solution, because global names will always seem to have an air of “special-ness” to them. Some kind of “original crate privilege.” Like how having an implementation of hashids named “hashids” is better than having a crate named “johnny-hashids.” One of them obviously came first, and even if that doesn’t actually make the “original” crate better, it’s something that we–as imperfect animals–still take into account.

To be fair, I pushed for namespaces a long time ago, basically as a result of seeing the proliferation of iron-specific crates with super-generic names like “router.” “iron/router” would have seemed to me to be a lot less abusive of a limited shared resource (like, you know, the global namespace)–but to have them as required going forward (rather than optional) seems to pretty obviously damage the options available to future users of cargo. Furthermore, if they aren’t required going forward, then I don’t see what this solves regarding the idea of squatting.

Reading through the entire thread just now gave me the impression that there are a good number of legitimate problems with this approach and, although there are also potential solutions to those problems here, I couldn’t shake the feeling that they seemed like patches on a tire–ad hoc solutions offered under duress, in the heat of the moment, so to speak. Anyway, if you’re trying to sell me a tire, I prefer a new tire, you know?

I know I sound like an old man, but having a problem does not justify having a solution. Having a problem can justify having the right solution, provided that the unintended consequences of that solution aren’t worse than the problem itself. I understand that one of the great benefits of open source is that we have a large number of people attacking problems from every angle, but we still have to remember that doing nothing is also a viable response to most problems.

So, for now, I still advocate doing nothing.


#55

I like the idea of namespaces, if the existing crates become part of the crates.io namespace, as part of a federated system.

That way, they aren’t special - they’re all just crates on an instance.

Using the short form, without specifying the namespace, would be deprecated and generate warnings, to further move away from the “specialness” of the default namespace - which is only necessary for backwards compatibility reasons.


#56

The opening post is still accurate, there were a few explanations that went into greater detail, but the questions asked did not produce any necessary changes. The only change made was to adopt RFC5785 in regard to the placement of the proof-of-control file as suggested by @TimNN.

I intentionally left out how the global namespace should be handled, because it’s not a necessary part of this proposal, it just makes multiple reasonable approaches possible.

This is largely a policy thing, and the right approach here is something that should be considered after namespaces work.

At the moment, you have various issues with the global namespace with very different causes:

  1. Names not available due to abandoned version 0.1 projects.
  2. Names not available due to name squatting.
  3. Names not available due to excessive reservation (“let’s register these names just in case I need it for my library”)
  4. Names not available due to the lack of a separate play/scratch namespace for tutorials and experiments.
  5. Projects not having a dedicated space for their crates (project foo can’t restrict usage of foo-* names).

This proposal makes it possible to address some – or all of them, depending on which policies for the global namespace are chosen.

For instance:

  • Deprecate the global namespace, introduce some “scratch” namespace for tutorials/experiments.
  • Use the global namespace as a sort of “vanity” namespace in which names are only assigned to well-established projects.
  • Keep the global namespace as-is, and let people publish to both.

Some of these changes (deprecate global namespace, put all crates on “equal footing”), might be more disruptive than others (keep the global namespace as-is), while others might be a net win (introduce a “scratch” namespace for tutorials and experiments).

There are valuable discussions to be had about this, but I think it makes sense to discuss this separately, so that disagreement about how to handle the global namespace doesn’t impede the debate about making namespaces as good as possible.

Can you point me to them? I don’t think I offered any ad-hoc solutions, but this might be a result of the brevity of the original proposal, which required additional explanations later on.


#57

I extended the original post. Let me know which questions are missing!


#58

I added your suggestion regarding RFC5785 to the proposal. Thanks!


#59

Much of your own replies to concerns are still not addressed in the main post.

First off just saying “No” begs the question on “Do I need my own domain?” why don’t you.

Your own post here: [Pre-RFC] Domains as namespaces

has a lot of points that are not addressed in the OP, but that you’ve addressed:

eg:

What’s the plan for referring to namespaced crates in rust code?

which IMO you’ve properly addressed with:

There isn’t any. This is intentional, because doing this would be a terrible idea. etc…

then there’s the refering to crates in cargo.toml, swapping domain depedencies, the potential issues brought up by refering to github.

This also isn’t properly addressed : [Pre-RFC] Domains as namespaces

There is still an impression of things that aren’t addressed because there’s no closed form “You asked this, this is the answer” here, its scattered through other primarily your own answers and other peoples questions, some of which went ignored (liked the thing I pointed out not being properly addressed).


#60

I wasn’t going to respond, but I just got hit with another deluge of news regarding internet censorship…

I cannot support this proposal or any like it in today’s political climate. My own political views are staunchly at odds with those of the Mozilla Corporation and those of much of the Rust team, and we live in a world where it has become acceptable to de-platform and un-person anyone whose political opinions are deemed incorrect by Silicon Valley. I cannot support any proposal that adds barriers to entry for creating software because software has become an essential element of speech and of the ability to commune with our fellow human beings.

I realize that the current state of crates.io (and other similar systems) is kind of annoying. I’m probably more affected by this than most people, because I create and maintain a pretty good number of libraries, and my first choice for a name is pretty much always taken. Still, I kind of just view it as a chance to be creative. That’s a price I’m willing to pay to allow people to create software and make it available to others without having to jump through hoops or seek the approval of a gatekeeping committee. (Note that I think of the domain-as-namespace thing itself as especially troublesome in light of recent developments, where registrars decide that a domain owner just isn’t allowed to have a domain anymore.)

Thank you for inquiring about my input. I hope you’ll take my concerns into consideration, regardless of what the community does or does not choose to do about this.