<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">1) It needs to be simple, allowing you
to publish a package within less than 1 hour of usage. Good
examples are <a class="moz-txt-link-freetext" href="https://hex.pm/">https://hex.pm/</a> for elixir,
<a class="moz-txt-link-freetext" href="https://pypi.python.org/pypi">https://pypi.python.org/pypi</a> for python, <a class="moz-txt-link-freetext" href="https://rubygems.org/">https://rubygems.org/</a> for
ruby, <a class="moz-txt-link-freetext" href="https://www.npmjs.com/">https://www.npmjs.com/</a> for node.js. Bad examples are
<a class="moz-txt-link-freetext" href="http://search.maven.org/">http://search.maven.org/</a> for java, <a class="moz-txt-link-freetext" href="http://www.cpan.org/">http://www.cpan.org/</a> for perl.
Maven is probably the best example of what is worst, due to the
process being as complex as possible and taking as long as
possible. The goal of the package manager is not to earn more
consulting money (I hope), i.e., consultant-ware.<br>
2) It needs to use source code in the packages, not binaries, to
make sure everything is transparent, avoiding black-box binary
blobs which lack any ability to be examined easily. Past erlang
package managers have had trouble here. Along with this, there
needs to be signing of the package for the identity of the
publisher and the integrity of the package.<br>
3) We don't need package dictators which attempt to decide what
packages are important, since that just limits the size of the
community, making this less of an open source effort (unless that
is the goal). You will notice the large open source communities
don't need to do this.<br>
4) It should be easy to utilize external build tools (like
autoconf/automake/makefiles) in a way that is the same as things
like rebar and emake due to the obvious problems doing non-Erlang
builds within an Erlang package (port, NIF and port driver
compilation support is unable to cover complex usage, i.e., it
lacks cross-platform support and dependency checking, these
shortcomings are likely to always be there, due to the effort
involved in tackling them seriously). It would be good to avoid
bikeshedding here and the potential for lock-in.<br>
5) It should not require a server running locally, just basic
client usage of a tool. If the package manager tool's execution
lasts beyond its usage, it doesn't look as simple as it should
(instead it just looks like a potential security problem). This
could include leaving epmd running which has been an issue with
past erlang package managers (puzzling potential users).<br>
6) Ideally, it should be easy to create a private package index
for private corporate usage of internal packages. It would be
nice to keep all the programming language usage in Erlang for the
sake of simplicity (there have been issues in the past with mixing
Python and other programming languages into the tool) and to keep
the dependencies limited. This is a great opportunity to show how
Erlang can shine to provide the community with simple package
management.<br>
<br>
On 12/16/2014 03:41 AM, Bruce Yinhe wrote:<br>
</div>
<blockquote
cite="mid:CAPbm=XE-bDShn+Z59-BJPQ5scX4D+3urk3+LaEfPe7P9NLDSvw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi everyone,</div>
<div><br>
</div>
<div>Industrial Erlang User Group (IEUG) has been working
together with the Erlang/OTP team to investigate and create a
package management system for Erlang/OTP. </div>
<div><br>
</div>
<div><span
id="docs-internal-guid-4c01f219-52c6-e367-afee-d2d2ca509f81">
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:13px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">The
lack of a package management system for Erlang has been
discussed for a long time in the community. In essence,
a straightforward package management system is believed
to take Erlang programming language a step forward.
Multiple tools will appear in the community. It needs to
be supported by a highly visible community behind it.</span></p>
</span></div>
<div><br>
</div>
<div>In order to increase the adoption and to result in a tool
widely used in the Erlang ecosystem, we are identifying the
most important user categories and use cases, based on what
the majority of the community want in a package manager.
Therefore we would like to invite an open discussion.</div>
<div><br>
</div>
<div>Now you are welcome to share your thoughts, suggestions or
proposals about an Erlang package manager. It would be great
if you could reply with your motivation, explaining why a
feature is necessary to have. There are some example questions
to begin the dicussion with, including, but not limited to the
following. </div>
<div>
<ul>
<li>What metadata information should an Erlang package
include?</li>
<li>What functionality do you need in a package manager for
Erlang in order to use it in production?<br>
</li>
<li>What other concerns do you have about an Erlang package
management system?</li>
</ul>
</div>
<div>
<div>Erlang package manager's brief wish list of features: </div>
<div>
<ul>
<li>Console interface<br>
</li>
<li>Web interface<br>
</li>
<li>Package Index and Repository</li>
<li>Fetch, Install and Remove Packages<br>
</li>
<li>Publish packages<br>
</li>
<li>Versioning and Dependency Management</li>
</ul>
</div>
</div>
<div>We are aware of several previous efforts and existing tools
that attempt to achieve the similar goal. We want to look at
existing things, both from Erlang and Elixir, to see if they
fit the requirements. If not, we will then have to make
something new, perhaps as a rewrite of an existing tool.</div>
<div><br>
</div>
<div>The IEUG members are putting together requirements for a
package manager and will work with the community and Ericsson
to create a standard and address any voids which exists in the
existing tooling, funding necessary efforts required. <br>
</div>
<div><br>
</div>
<div>Best regards</div>
<div><br>
</div>
<div>Bruce Yinhe</div>
<div class="gmail_signature">
<div dir="ltr"><font size="1">
<div dir="ltr"><br>
</div>
Erlang Community Manager</font>
<div><font size="1">Industrial Erlang User Group<br>
<a moz-do-not-send="true"
href="mailto:community-manager@erlang.org"
target="_blank">community-manager@erlang.org</a></font>
<div><font size="1">+46 72 311 43 89</font></div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>