[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

[Steve Strong]

As a plan, I like it. Why? Because it's simple, and therefore it has a
chance of working.

If it gets done, and if it then gains traction, the fancier stuff (signing,
cleverer version management etc) and removing proprietary dependencies
(github) can be added over time.

Cheers,

Steve
On 18 Feb 2014 19:50, "Gordon Guthrie" <gordon@REDACTED> wrote:

> Loic said:
>
> > This is what makes these package manager discussions so odd. People keep
> talking about technical choices and how the perfect package manager they
> have wet dreams about so often would look like, and nobody asks the
> questions that matter: how do people deal with dependencies today? How can
> we improve the workflow? Do packages need to be separate (meaning you need
> to convince people to maintain them, how?) or can the library authors do
> it? How do you convince library authors to agree to it? Is their investment
> in this worth the reward?
>
> > It doesn't matter what the technical solutions are until we have a
> clearer idea of what people want and would be willing to use. All package
> manager projects are bound to fail until these questions are answered.
>
> Spot on.
>
> Let me be a little clearer about what I was proposing.
>
> What Is The Problem?
> --------------------
>
> There are lots of open source Erlang packages that I don't know about that
> I ought to be including in my project.
>
> How Do I Find Packages?
> -----------------------
>
> Somebody tells me.
> I google and find a StackOverflow question that links to a package
>
> How Do People Create Open Source Erlang Now?
> --------------------------------------------
>
> They create a public repository on GitHub.
>
> (Yes you can self-host your repository, you can use Mercurial or Bazaar or
> what ever, but as the Senator said when he failed to be re-elected "the
> people have spoken, the bastards".)
>
> How Do People Include Open Source Erlang?
> -----------------------------------------
>
> rebar get-deps
>
> (yes there is relx and erlang.mk, but rebar get-deps is generally how
> people do it).
>
> How Are Dependency Clashes Resolved?
> ------------------------------------
>
> If I want to use a package that depends on Cowboy 0.6.0 and another on
> that depends on Cowboy 0.8.1, tough.
>
> How Do People Ensure That The Software They Are Installing Is Secure And
> Safe?
>
> ------------------------------------------------------------------------------
>
> Richard O'Keefe said:
>
> > Anything that expects people to trust an unknown makefile not
> to do evil things while installing had better have some
> really *serious* security and authentication on it.
>
> Bless!
>
> The problem, of course, is kids today! Even old
> 'started-programming-on-punch-cards in-the-70s' farts (comme moi) are
> 'drinkin beer, smokin fags and installing random software from the
> interwebs' - (haven't smoked a fag for 22 year, but I'm still a
> metaphorical 80-a-day man)
>
> I know, I know, its not big and its not clever...
>
> Commercially you inspect the package and snapshot it to your private
> GitHub repository and build and deploy from that.
>
> What Am I Proposing?
> --------------------
>
> * a list of open source software
>   - which is SEO-friendly and comes top of the search page
>   - this is why I suggested merging it with the revived erldocs - mucho
> SEO juice
> * which the 'owners' of that software choose to join
>   - commit a single Erlang term file to your repository
>     > proof that you want to join
>   - post the URL to a crawler robot
>     > if the term file is there your page will be generated
>        - a Jekyll site would be the easiest
>        - keywords in URLs
>        - titles/H1/H2/SEO stuff
>        - tags/categories for free
>   - it needs to be a community
>     > the authors need to care about their reputation
>     > you can't spam people into a 'community'
> * that generates instructions on how to incorporate that software in your
> project
>   - probably mostly 'add this line to your rebar.config'
>   - or 'add this line to your package.txt for erlang.mk'
>   - or blah-blah relx blah-blah (don't know enough about it)
> * that has enough primitive social indicators to constitute a feedback loop
>   - scrape stars, forks, commits, watches, date of last commit from GitHub?
>     > or some sort of voting/reputation system (sounds like a pain in the
> arse to write)
>   - and Disqus commenting (generate SEO keywords)
>
> What I Am Not Proposing?
> ------------------------
>
> * something that scrapes and builds and verifies and cryptographically
> signs software packages.
> * a continuous build server that will produce verified builds for multiple
> architecture
>    - you can use Travis-CI to do that for open source projects - you would
> want to pull their results in - good social signal
> * something that makes extensive us of GitHub apis
>
> The General Principles
> ----------------------
>
> * small problem solved well
> * loose coupled
>   - so it can evolve to address 'harder' problems
>
> Gordon
>
>
>
> On 18 February 2014 17:18, Miles Fidelman <mfidelman@REDACTED>wrote:
>
>> Loïc Hoguin wrote:
>>
>>> On 02/18/2014 04:47 PM, Garrett Smith wrote:
>>>
>>>> emerged as a de facto standard (i.e. actually *used* by people)
>>>>
>>>
>>> This is what makes these package manager discussions so odd. People keep
>>> talking about technical choices and how the perfect package manager they
>>> have wet dreams about so often would look like, and nobody asks the
>>> questions that matter: how do people deal with dependencies today? How can
>>> we improve the workflow? Do packages need to be separate (meaning you need
>>> to convince people to maintain them, how?) or can the library authors do
>>> it? How do you convince library authors to agree to it? Is their investment
>>> in this worth the reward?
>>>
>>> It doesn't matter what the technical solutions are until we have a
>>> clearer idea of what people want and would be willing to use. All package
>>> manager projects are bound to fail until these questions are answered.
>>>
>>>
>> Really good points.  One nice thing about Erlang packages - we're talking
>> about a single language and run-time environment, not upstream code that
>> has to be packaged for every linux distribution under the sun.
>>
>>
>>
>>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
> --
> ---
> Gordon Guthrie
> CEO vixo.com
> @gordonguthrie
> +44 (0) 7776 251669 (in Bonnie Scotland!)
>
> vixo is made in Scotland from electrons
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140218/4ce7ee6e/attachment.htm>