Hello I am interested to see that while making a deployable elixir release, the release system can bundle in the dynamically linked binaries like openssl Would that amount to the same effort on the elixir team's end?
It would be great to be able to create desktop apps(non gui) using elixir Regards R On Tuesday, May 28, 2019 at 4:05:30 PM UTC+5:30, dch wrote: > > On Tue, 14 May 2019, at 16:49, Thomas Cioppettini wrote: > > Hmm this might be a nice side project. I think we could start with the > > most common environments and build out from there. Based on some quick > > research this may be more automatable than you may think. Based on what > > I've seen most projects just are linking to the github archive and > > hardcoding a hash of the contents. If that's it, then it should be > > fairly reasonable to just update it. I'll do some more research and get > > back to you. > > > > On Monday, May 13, 2019 at 2:35:20 AM UTC-4, José Valim wrote: > > > Hi Thomas, > > > > > > It is not possible for us to handle all of the different OSes and > package managers, manage permissions, debug errors, etc. Publishing is only > one part of the process. > > > > > > However, we will be glad to improve our current "broadcast" > infrastructure, so whenever we publish a new version, everyone can receive > an event and have their automation tool publish to the OSes they consider > common. Today you can get those events either via the google groups OR via > the GitHub releases page (which provides a feed IIRC). > > > > > > *José Valim* > > > www.plataformatec.com.br > > > Skype: jv.ptec > > > Founder and Director of R&D > > > > > > > > > On Mon, May 13, 2019 at 6:39 AM Thomas Cioppettini <t...@scalpel.com> > wrote: > > >> I think we should manage the distribution of elixir to common package > managers after a release has been built. > > >> > > >> Right now we rely on other maintainers to be aware that elixir has > been updated, and do their respective work to add the most recent package > to their repository. This process is slow and unreliable, we should > automate it so that the most recent versions of libraries are available > everywhere. > > Hi Thomas, > > This is a desirable goal & I don't want to dissuade you, but this is a > surprising amount of work, often requiring manual tweaking that requires a > reasonably deep understanding of how packages and package managers work on > a given system. > > <combinatorial explosion> > The end result is that you begin to ship a custom OTP release, including > static OpenSSL, and having your own per-OS custom package repos, to try to > keep up. Then you find out that popular project X doesn't yet support that > version of OTP, so now you ship multiple OTP releases per Elixir release. > Phoenix, RabbitMQ, & CouchDB are well-known projects with varying bits of > Elixir on the inside. > </combinatorial explosion> > > That said, https://repology.org/project/elixir/versions may well be a > useful place to start for somebody who is interested in hunting down what's > lagging behind and submitting patches. Its source code is > https://github.com/repology/repology & > https://github.com/repology/repology-rules, and a neat hack would be, > after X days after a release, to send a gentle reminder to the maintainers > listed for any lagging downstream distros. Or, to post the list to > elixirforums and recommend people contribute patches for their favourite > distros. > > I think that having an announce@ list and encouraging maintainers to > subscribe, is your biggest win for the least effort. It's certainly > shortest in LoC :-) > > A+ > Dave > -- 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-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/53d1dffe-171c-48d8-9fd1-3b7b2221d47a%40googlegroups.com.
