Module namespacing

[Alexei Sholik]

Has anyone considered the possibility that some time after 1.0 release Elixir adds a new module, it'll break user code?

Some background: currently _literally everyone_ defines their modules in the same namespace as standard library modules. And I'm not referring to the fact that Elixir's modules live in a global namespace (like Erlang's).

What I'm saying is that `mix new proj` creates a project that has a module called Proj. So it is easy to imagine that if Elixir adoption continues to grow at a gradually increasing rate, the top-level module namespace will be filled with hundreds of short and long names.

If Elixir decides to introduce a new module at basically any point, an appropriate name for it may already be taken. Or it will break the code in some closed-sourced application nobody knew about.

My question is: did I miss anything that makes it a non-problem?

If not, what's the plan to prevent breakage or blockage of new modules being added to Elixir?

--
Best regards
Alexei Sholik

[Eric Meadows-Jönsson]

I don't think there is a way around it unfortunately. The same issue arises when adding functions to Kernel, or really any module, since they can be imported.

We can recommend people to not name their libraries/applications to nouns, use a proper name instead. For example, name your JSON library modules "Jazz.*" instead of JSON ;), since Elixir may decide to add a JSON module.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Eric Meadows-Jönsson

[Saša Jurić]

That's an interesting point. Back in my C# days (now almost 10 yrs ago :/) the advice was to use company/app name as a top level namespace for everything you write yourself.

I wonder if it makes sense enforcing this through mix.exs? On first thought, I wouldn't mind if mix.new would automagically prepend all of my modules with YourProject or something similar, as long as I can easily:

1. alias YourProject.**

2. set YourProject to something more meaningful, presumably in mix.exs

By default, I'd have to use YourProject.MyModule which would force me to set the corresponding property immediately if I intend to publish my lib.

Could something like that work?

[Alexei Sholik]

Saša, is it really a problem in C#? It has namespaces, so, clashes between 3rd party libraries aside, it should be impossible to clash with the standard library if it resides in its own namespace.

In C++ stdlib is in the "std" namespace which cannot be modified by 3rd party code. (Well, it doesn't forbid the modifications per se, but you'll get undefined behaviour if you make any, in the best C++ tradition[1]).

In Elixir, there is no similar mechanism. But as an option, instead of imposing conventions on the users, the stdlib itself could have a naming convention.

In the Apple world of Objective-C, 2-letter prefixes are generally reserved for system frameworks. So NSDictionary, GKUser, etc. are classes from system frameworks.

I came up with a couple of possible conventions for Elixir:

* name std modules with Ex prefix: ExEnum, ExModule, ....

* make it a "namespace": Ex.List, Ex.Node, ...

And if there will also be support to "flatten" the standard namespace like this: alias Ex.* as Saša suggested, it will not be a nuisance.

Sure, this will make the use from Erlang uglier: Elixir.Ex.Enum. But at least it's something the language can guarantee: the fact that any new modules will only be added under Ex. "namespace".

We can devise conventions for users, but those can't be guaranteed to be conformed to.

[1]: https://www.securecoding.cert.org/confluence/display/cplusplus/MSC34-CPP.+Do+not+modify+the+standard+namespace

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Meadows-Jönsson]

We cannot implement alias Foo.*. It would require us to know all modules upfront, which is impossible.

Eric Meadows-Jönsson

[Alexei Sholik]

We can know all standard modules upfront.

[Eric Meadows-Jönsson]

Yes, we could. But we want to special case as few things as possible.

Allowing alias Ex.* would just bring the same problem back. If someone uses it we are back in the same place where adding something to Ex.* would be a potentially breaking change.

[Alexei Sholik]

That is certainly true, but that was just a suggestion. The gist of my comment was about namespacing all standard Elixir modules.

If nothing else, having a list of

alias Ex.Node

alias Ex.List
...

at the beginning of a source file could serve documentation purposes to briefly show the amount of standard stuff the current file/module depends on. This will of course be purely optional.

[meh.]

On Wed, May 14, 2014 at 11:40:46PM +0200, Eric Meadows-Jönsson wrote:
> We can recommend people to not name their libraries/applications to nouns,
> use a proper name instead. For example, name your JSON library modules
> "Jazz.*" instead of JSON ;), since Elixir may decide to add a JSON module.

That's case since the release on hex.pm :)

[Paul Schoenfelder]

I agree that this is a potential problem, but at least my practice so far has been to namespace all my modules under `ProjectName.*`. Perhaps there is a way to encourage that via mix, the getting started guide, etc. Now, if I name my project Enum for some stupid reason, then I think the best approach is to have a compile error, something along the lines of "This is a standard library module name, usage of standard library module names are not allowed.". Alternatively, we could have all the standard library modules namespaced under `Elixir.*`. I know technically everything already is, but what I mean is an additional level of Elixir. So we'd end up with `Elixir.Enum` which compiles to `Elixir.Elixir.Enum.beam`. Just a thought anyways. I think it makes more sense than `Ex.Enum` myself.

Paul

[Alexei Sholik]

I would like to summarize some considerations that popped up during discussion on IRC.

First of all, ericmj rightly pointed out that there are more ways that could break user code than just module name conflicts:

20:02 ericmj: adding a function Kernel can break code
20:03 ericmj: adding a function to ANY module can break code

The last point is true when you import the module in question.

Now back to module names. A convention for module naming that everyone seems to agree with is to use a prefix for all user-defined modules. So, if I have a project called Foo, it will have modules like Foo.App, Foo.Util, Foo.Config, etc.

But since standard Elixir modules also use such namespacing, an unfortunately picked name for the root prefix (like User) could result in a conflict: say, User.Config is added to stdlib.

What if Elixir itself used single-level module names? String.Unicode would become StringUnicode, ExUnit.Case would become ExUnitCase and so on. This would allow it to convey a clear message about user module naming: use at least two components in your module names (as in Root.ActualName) and you won't ever be affected by new modules added to stdlib.

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Best regards
Alexei Sholik

[José Valim]

What if Elixir itself used single-level module names? String.Unicode would become StringUnicode, ExUnit.Case would become ExUnitCase and so on. This would allow it to convey a clear message about user module naming: use at least two components in your module names (as in Root.ActualName) and you won't ever be affected by new modules added to stdlib.

If the language itself uses a foreign single-level namespacing rule, the consequence will either be:

1. The language will look weird (because it follows a rule that is not followed anywhere else)

2. Everyone is going to follow the language (and then the problem will still exist)

In any case, my recommendation would be to not define anything inside any existing namespace that belongs to someone else. If Elixir defines a String module, don't go define something like String.MyModule. As you should not define something inside the Jazz.* namespace if you use the Jazz project.

In the future, the least we can do is to warn upcoming modules in advance. If we are going to ship with Date and Time in 1.2, we can tell at least 6 months before of such changes coming in 1.2 allowing libraries to catch-up/rename. Note that we have already reserved some obvious ones, like Atom, BitString and so on.

Afaik, this issue exists in many languages, it would be interesting to know how they are handling their development cycles.

[johnny....@gmail.com]

I'm a huge fan of the EcmaScript 6 module system--it works very well and completely avoids name kludges, because you can import modules with whatever name you like. Something like that in Elixir would be awesome.

[Jason M Barnes]

Are you looking for something different than:

alias VeryLong.ModuleName, as: Short

?

Jason

On Fri, Oct 2, 2015 at 5:03 AM, <johnny....@gmail.com> wrote:

I'm a huge fan of the EcmaScript 6 module system--it works very well and completely avoids name kludges, because you can import modules with whatever name you like. Something like that in Elixir would be awesome.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/169703cd-302d-43e5-bf2c-077a738ee42c%40googlegroups.com.

[Booker Bense]

On Thursday, May 15, 2014 at 1:25:07 PM UTC-7, José Valim wrote:

Afaik, this issue exists in many languages, it would be interesting to know how they are handling their development cycles.

There are two models that I am aware of, the first is the current Elixir situation: 

1. Land Grab - first one wins, everybody else pick weird names like the japanese word for chainsaw ( xml parser ) 

2. Categories - There is a general module namespace for say XML and people create module with unique names in 

                         that namespace. ( Perl mostly does this ) The central repo generally enforces the namespacing 

                         requirement. 

The first leads to things like bundler and you need good documentation and search engine to find what you need.

The second makes things easier to find, and was very common for most projects in the days before google and github.

For languages that have arisen in the post-google era, Land Grab seems the most common. 

While the second looks like it would help with the conflicting functions problem, it generally doesn't as people import

functions accessible without the full module path. Every language that has modules seems to have a way to shortcut

the long function names that a categorized module space requires. It does put all the modules that implement X on

an equal playing field. However, IMHO it tends to discourage alternate implementations since 3rd party modules feel more 

"official" some how. 

My preference is the first because it allows the compromise of using the full module name without too much visual 

pain. This of course implies that you have reasonable autocomplete support in your editor. I also think it encourages

experimentation and alternative implementations. In Ruby there are several cases of alternative implementations 

of standard modules eventually replacing the ones in the standard library. 

While function collision is a problem, I'm not sure that any of the solutions are better. 

The one thing that seems somewhat unique to Elixir in my experience is the 

overriding influence of Kernel functions. While there is a straightforward workaround

if a new function shows up in kernel that matches your function, it does

suggest that the bar for new functions in Kernel should be quite high. 

(i.e. a New Kernel function should be a major release, not a point release. ) 

A lot of how this is handled is determined by how complete the standard distribution 

is; if you are going to have 'soup to nuts' in the standard libraries then you likely

forced to start categorizing modules in the standard distribution and people 

will just follow on to that example. 

Erlang is an exception here, it does have a very large collection of stuff in the

standard lib with a mostly flat name space.  I can see both good and bad 

things with that approach. 

Elixir's current standard lib is quite lean, and as long as there is strong infrastructure

around accessing 3rd party libraries, I think that's actually preferable. It's important 

to remember that the more things in the standard library, the greater the maintenance 

burden on central maintainers. Even in popular languages like Ruby, there are modules

in the standard distribution that are essentially abandonware.

Having some direction about where Elixir is headed wrt lean core vs fully loaded

would help a lot in this debate. 

- Booker C. Bense 

[johnny....@gmail.com]

@Booker there's an option #3 which is what Javascript ES6 modules do (used by Node.js etc.).

Suppose I have two files, "/foo.js" and "my_folder/foo.js" which both define a variable called Foo. If I want to use both in my app, I can do:

    import Foo1 from './foo';

    import Foo2 from './my_folder/foo';

When files are loaded, they do not dump their variables into the global namespace. Since I've imported the above as Foo1 and Foo2, calling Foo itself in my app file will return a "variable not defined error." In other words, the contents of "/foo.js" and "my_folder/foo.js" are sealed; there's no leakage of variables from these files elsewhere.

Now, I realize in Elixir it is possible to do require Foo, as: Foo1. This is close to what I'd want, but there are some problems IMHO:

1) The as: keyword sets up an alias, however the original variable also becomes accessible (I call this "leakage").

iex(1)> Integer.is_odd(3)

** (CompileError) iex:1: you must require Integer before invoking the macro Integer.is_odd/1

iex(1)> require Integer, as: Foo

iex(2)> Foo.is_odd(3)          true

iex(3)> Integer.is_odd(3)      true

2) In Javascript Node.js it is possible to use different versions of the same 3rd party lib in the same process without worrying about name kludges. For example, if LibA requires LibC version 1.0, and LibB requires LibC version 2.0, you'll have no problems fetching BOTH versions of LibC, and LibA will use 1.0 while LibB uses 2.0.

Mix/Hex (and also Ruby's Bundler) force you to fetch only one version of each 3rd party lib, and if you can't find a suitable version fit it fails to bundle. It looks like Hex provides an $ mix deps.unlock override mechanism, but still this is forcing you to use a single version of each dependency.

[Ed W]

On 02/10/2015 16:02, Booker Bense wrote:

> There are two models that I am aware of, the first is the current
> Elixir situation:
>
> 1. Land Grab - first one wins, everybody else pick weird names like
> the japanese word for chainsaw ( xml parser )
>
> 2. Categories - There is a general module namespace for say XML and
> people create module with unique names in
> that namespace. ( Perl mostly does this ) The
> central repo generally enforces the namespacing
> requirement.
>

This is a fantastic summary of something I had been pondering how to
write for a while.

My preference is very strongly on 2. I find it vastly easier to guess
what Net::Imap::Server::Async does and find it in a list of possible
options. Google lists stuff by "popularity" (ie requires module authors
to invest time popularising their product rather than just coding it)
and if CPAN is a guide to go by, as a language matures, one often ends
up with 15 competing implementations of any idea, each flawed in various
subtle ways and none necessarily emerging as an all encompassing
version, necessarily this encourages yet more attempts to fix the
problems with all previous modules... (cue the XKCD on "Standards").

(Note: CPAN has recently introduced the idea of "reviews", which in many
cases has produced fantastically detailed essays on the pros/cons of a
group of related modules from experienced users. Think "Which JSON
module to use" which compares speed, ease of integration, dependency
management, error handling, malformed input handling, etc. This would
be an interesting feature for Hex to learn?)

Anyway, completely pointless me offering an opinion unless I start mass
producing great quantities of modules and influencing opinion. I think
if 2) were desired then it would need guidance from "on high".

Thanks for writing up the situation though - great elaboration of the
status quo!

Ed W

[johnny....@gmail.com]

On Tuesday, October 6, 2015 at 6:44:52 AM UTC+9, Ed Wildgoose wrote:

My preference is very strongly on 2.

What about Option #3: "Don't pollute the global namespace."

Here's an implementation in Ruby which should have been made the standard IMHO, but too late! https://github.com/soveran/cargo

[Redvers Davies]

On Wed, Oct 7, 2015 at 9:43 AM, <johnny....@gmail.com> wrote:

What about Option #3: "Don't pollute the global namespace."

Well, arguably how the modules are organized and loaded in your program should be your choice which is really what option #3 is all about and provided for already by Jose's alias VeryLong.ModuleName, as: Short

Jose's statement solves the problem for the language directly but the issue with package management at scale with the landgrab model is hard, very hard.

Hierarchy in package management scale better both for users and repo maintainers as you can delegate management on a per-namespace basis.  Critically, you can delegate management in a namespace to people who have expertise in that field(!).

Don't get me wrong I like cute names as much as anyone but singular namespace means you can't browse a repo only search.  On man, I LOVE browsing repos but with no hierarchy the only browse options you have are alphabetical, by downloads or by date :-/

Example:

If I search on hex.pm for 'email' I get:

mailer - 'A simple email client'

aeacus - 'A password authentication module'

echo - 'A notification system'

hermes - 'A component for sending and receiving emails' (and an education that hermes comes from the greek messenger of the gods).

mailibex - 'an email library in elixir that implements dkim, spf, dmarc, mime, ...'

Where's mailman, mailer or gen_smtp?
Missing, because they chose the term 'mail' as opposed to 'email' or smtp.

Searching leads to SEO optimization, SEO optimization leads to function bloat, function bloat leads to the dark side.

Hierarchies conversely encourage module specialization and separation of concerns and that's a good thing.

As was mentioned in a previous conversation on the subject it may be too late or too hard to encourage library developers to move to hierarchical namespaces.  Perhaps most of the advantages can be had by layering hierarchical categories onto the existing code such that those can be browsed to provide the same user experience.

Thanks,

Red

Naming advice from PAUSE is superb and I'd encourage anyone to read it:
https://pause.perl.org/pause/authenquery?ACTION=pause_namingmodules

[Booker Bense]

On Saturday, October 3, 2015 at 12:49:16 PM UTC-7, johnny....@gmail.com wrote:

2) In Javascript Node.js it is possible to use different versions of the same 3rd party lib in the same process without worrying about name kludges. For example, if LibA requires LibC version 1.0, and LibB requires LibC version 2.0, you'll have no problems fetching BOTH versions of LibC, and LibA will use 1.0 while LibB uses 2.0.

Mix/Hex (and also Ruby's Bundler) force you to fetch only one version of each 3rd party lib, and if you can't find a suitable version fit it fails to bundle. It looks like Hex provides an $ mix deps.unlock override mechanism, but still this is forcing you to use a single version of each dependency.

Well, the erlang runtime supports having two versions of a module for hot code swapping.
But that doesn't really address the problem.

My initution is that the structure for doing module versioning for dependencies is possible in Elixir, but it would require tweaking the
module name to include the version under the covers. Elixir already does this by appending Elixir in front of all the Elixir modules

iex> .c.m

iex(2)> :c.m
Module                File
Elixir.Access         /usr/local/Cellar/elixir/1.0.5/bin/../lib/elixir/ebin/Elixir.Access.beam
Elixir.Access.List    /usr/local/Cellar/elixir/1.0.5/bin/../lib/elixir/ebin/Elixir.Access.List.beam

The vsn tag is in every module, so it could be appended to the "erlang" name of the module.

Elixir functions already have a unique context, so if you can solve the injection version into
module name problem, the rest is straightforward.

Solving that problem in a way that is usable seems like a fairly high hurdle. While it looks nice,
debugging such a system seems like a potential nightmare. Sometimes the solutions are worse
than the problems. To me this seems like something that needs support in the VM, hacking solutions
on top via namespace mangling has a long history of being a mis-feature.

Another solution to this problem is to run the libraries in separate Unix processes. This of course
is a problem in most languages due to the RPC overhead. However, by using the BEAM we get
this for nearly free. This solution isn't ideal, but if we can reduce the tooling friction around creating
such solutions IMHO, this is a much better solution to the problem of conflicting dependencies.

Much of the momentum around micro services is driven by exactly this kind of dependency conflict
in big applications. The BEAM gives us a really simple and straightforward way to implement these
kinds of micro services.

To reiterate, the solution is that rather that tying ourselves in knots trying to keep one namespace clean,
we work on making the tools around using multiple namespaces easier to use.

- Booker C. Bense

[Paul Schoenfelder]

My initution is that the structure for doing module versioning for dependencies is possible in Elixir, but it would require tweaking the module name to include the version under the covers. Elixir already does this by appending Elixir in front of all the Elixir modules

This would destroy compatibility with other BEAM languages if I'm understanding you correctly, at least in the sense of them consuming Elixir modules.

Erlang is also not really compatible with running multiple versions of an application at once. I mean, yes, you can potentially have two versions of a module running side-by-side during an upgrade, but that is handled entirely by the runtime, and only occurs if processes are in the middle of handling a request during an upgrade (old version handles the in-flight request, new version handles new requests). Hot upgrades/downgrades require a single source version and a single target version, so those would become significantly more complex to manage. What about applications that register local/global names? What about applications which expect to create/manage a named ETS table? If you have multiple versions of an application loaded at once, things get really hairy when you start thinking about ways in which they could conflict.

I think that, fundamentally, versioned modules aren't compatible with Elixir, same with running multiple versions of an application to satisfy transitive dependency requirements. The potential difficulty in sorting out your dependencies up front so that you are only running a single version of each application in your dependency tree, is also what makes some very complex problems seem rather easy thanks to Erlang/OTP.

Paul

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ff0944d4-eb41-4eb3-a3d7-cce209cf216f%40googlegroups.com.

[Paul Schoenfelder]

Every file should define what it exports, and also what it imports. It looks to me like Elixir has abandoned Erlang's elegant module system in favor of Ruby-style global namespace dumping.

This is exactly what Elixir modules compile to, `defmodule Foo` is equivalent to `-module('Elixir.Foo')`, `def` is equivalent to `-export`, and so on.

Paul

On Wed, Oct 7, 2015 at 1:24 PM, <johnny....@gmail.com> wrote:

On Thursday, October 8, 2015 at 1:46:20 AM UTC+9, Paul Schoenfelder wrote:

This would destroy compatibility with other BEAM languages

Why not use Erlang's own module, export, and import semantics in Elixir?

   -module(count_to_ten).

   -export([count_to_ten/0]).

   -import(io_lib).

 

   count_to_ten() -> do_count(0).

Every file should define what it exports, and also what it imports. It looks to me like Elixir has abandoned Erlang's elegant module system in favor of Ruby-style global namespace dumping.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/b240f1fe-90ea-4d33-a2ad-4a5dd3b1cdee%40googlegroups.com.

[Eric Meadows-Jönsson]

Where’s mailman, mailer or gen_smtp?
Missing, because they chose the term ‘mail’ as opposed to ‘email’ or smtp.

Hex provides full text search of the package description field so as long as you include the word in your description it will be found. Another solution is to create a website that categorises Hex packages so you can easily find all emailing packages. Hex provides an HTTP API you can use to retrieve all packages.

My initution is that the structure for doing module versioning for dependencies is possible in Elixir, but it would require tweaking the
module name to include the version under the covers.

This would not be enough because you can still only only have version of a given application. So you would need to inject the version into the application name, into the name of all registered processes and into everything else global and unique in the system.

I would love to do hierarchical packages in Hex but it is simply not possible, which is why Hex goes through great lengths to have a great dependency resolver to find a compatible set of dependencies.

​

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TsG-kjSe4Z1jPMv2kmSLKd%2BD8J_kD9PhvDHgfCUY%2Bk6bQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Eric Meadows-Jönsson

[Daniel Marin Cabillas]

Hi all,

Just a simple idea, what about providing a tag system for hex packages? 

I think that could help to discover libraries by topics, as long the authors pick the right tags (xml, json, parser), then we could build an categorized index.

[Eric Meadows-Jönsson]

> as long the authors pick the right tags (xml, json, parser)

This is the hard part. In my experience users rarely use correct tags and it's too much work for admins to go around verifying that tags are correct. A curated index or community curated index (sort of like how stack overflow allow users to correct tags) is needed and that is out of scope of Hex itself. I would be very glad to see a website that provide functionality like this.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9b0ae518-cb38-4755-b18d-7bb701085020%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Eric Meadows-Jönsson

[Josh Adams]

If we allowed users to pick tags, and supported a PR-friendly way to
add tags (where other tags just don't show up in a list) it might be
better? I think it would be a useful bit of metadata to have in Hex.
It would at least help to provide a top-level of organization. Even
if hex didn't use tags to show categories itself, it would enable
other categorization-repositories to potentially flourish on top of
the foundational data. One would assume it would become common for
tiny PRs to help authors categorize, in the same way that tiny typo
corrections are trivial-but-useful PRs to a random project you're
looking at.

Just a thought. Certainly don't want to add any extra work on core
team members, but it seems like a foundational language feature of
sorts.

> https://groups.google.com/d/msgid/elixir-lang-core/CAM_eapj%2BpkeWtEspSHdd8MGYk3EEFrBMoSVaEFEdHA9BOzFPvg%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Josh Adams

[Redvers Davies]

What Eric said.  I'm pretty sure this gap will be filled momentarily ;-)

The issue with tags is two-fold.  Firstly, they're typically not hierarchical and secondly that you can have multiple tags.

If someone has written a library which needs more than one tag two things may fall from this:

1. Chances are it could / should be separated into two different packages.
2. It doesn't encourage 'tag creators' to be strict with their creation.  Think of tags as like :atoms, we want to encourage as much as possible people to use .to_existing_atom over .to_atom.

Thanks,

Red

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM_eapj%2BpkeWtEspSHdd8MGYk3EEFrBMoSVaEFEdHA9BOzFPvg%40mail.gmail.com.

[Eric Meadows-Jönsson]

> If we allowed users to pick tags, and supported a PR-friendly way to
add tags (where other tags just don't show up in a list) it might be
better?  I think it would be a useful bit of metadata to have in Hex.

It's not a question of ease-of-use for users, it's about the scope of the package manager and the work load of admins. This feature will require maintenance from maintainers (currently me and some helpful contributors on github). The extra maintenance is not a big deal because it's a fairly small feature but everything that detracts from the core goals of the package manager means it will take longer until we have mirroring, registry signing, package signing, testable packages, cross repository dependencies and so on. These features can only exist in the package manager but the job of tagging can easily be handled by an external project because Hex provides the API to do so.

It will require extra work from admins to moderate the tags to make sure packages are correctly tagged. Currently I am the only admin for Hex.pm and my workload is already more than 50% on administrative and moderation tasks, rather than working on new features and fixing bugs. That workload division is certainly not good and it's not going to scale in the future.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CA%2BV9ejHQV6p4LYnUfQSkTZWfajMep4D2mP9zccHzp%2BHUifU--w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Eric Meadows-Jönsson

[José Valim]

They can't be done with PRs as everything is in Hex' database. I can't see any other way besides what Eric proposed. And there are many other things the Hex team should focus on including guaranteeing everyone can reach their packages as fast as possible during deployments.

Hex is a very essential piece of structure and the Hex team should be focused on that. We need a bigger team and a very active group of contributors before we start focusing on things like "community features". So unless folks step in and are willing to build, develop and maintain those features and others, I really don't think this should happen.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAA1-O0wkLF_%2Bcfwk0%2B7H-UTfZ-JJB%2BCM%2Bwm2O-hYs5942mHgXw%40mail.gmail.com.

[Ed W]

On 07/10/2015 15:48, Redvers Davies wrote:

> Jose's statement solves the problem for the language directly but the
> issue with package management at scale with the landgrab model is
> hard, very hard.
>
> Hierarchy in package management scale better both for users and repo
> maintainers as you can delegate management on a per-namespace basis.
> Critically, you can delegate management in a namespace to people who
> have expertise in that field(!).

Agreed. And in the case of perl, when a module author decides to "own
the world", you tend to see a new root appear, eg "mojolicious" or
"AnyEvent". Also I don't think the structure is terribly restrictive in
practice, again when someone has a go at a "reboot" of a genre there are
usually other words which work, eg the "Mail::Box" and "Email" projects
which basically have several tries at getting email parsing right.

Personally I like well named hierarchies, but I think this will require
an edict from on-high to become law...

Cheers

Ed