Code Archives (Turning rebar into a package manager) - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Code Archives (Turning rebar into a package manager)
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
Mime-Version: 1.0 (Apple Message framework v1278)
From: Tim Watson <watson.timo...@gmail.com>
In-Reply-To: <9DEFCD8EB8743E4EA623A12F453B66FCE...@ESESSMB207.ericsson.se>
Date: Wed, 31 Oct 2012 14:05:01 +0000
Message-Id: <0CD34A6A-8178-4187-BFF1-5EE7941CB...@gmail.com>
References: <CAANBt-om0_w2PqWjdwdNOdCewOx8-6zRB2AT=Jru1O1OVJJ...@mail.gmail.com>
 <50814888.3050...@ferd.ca>
 <CAANBt-qvztTwyUNQ1K3x6VNRi1Yw+wt4gesH39+HQbswiwt...@mail.gmail.com>
 <508FA0E1.2080...@gmail.com> <BDE323DE-AC12-415E-8B27-E3A0EA90D...@gmail.com>
 <CAEVpa77iZDhKqZZBNnEenGjkvZK_8VUsdiqn8iDB2=pNQcR...@mail.gmail.com>
 <CAANBt-pLNRrUDwn0xxVSOT3bctMxiP3MZdYW-KZyVoV3JBz...@mail.gmail.com>
 <CAANBt-rKKYRyWiAgOCU=vAkvqRWzGMoBQyi8U43B2UjWpQw...@mail.gmail.com>
 <9DEFCD8EB8743E4EA623A12F453B66FCE...@ESESSMB207.ericsson.se>
 <515ACAFF-565D-49DD-AC94-72D6B1E6D...@gmail.com>
 <9DEFCD8EB8743E4EA623A12F453B66FCE...@ESESSMB207.ericsson.se>
To: Ola Andersson A <ola.a.anders...@ericsson.com>
Cc: Erlang <erlang-questi...@erlang.org>
Subject: Re: [erlang-questions] Code Archives (Turning rebar into a package
	manager)
Precedence: list
Content-Type: multipart/mixed; boundary="===============7266185332185684313=="
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org


--===============7266185332185684313==
Content-Type: multipart/signed; boundary="Apple-Mail=_4B05416A-81AD-4EFF-9A12-84612309E1AB"; protocol="application/pgp-signature"; micalg=pgp-sha1


--Apple-Mail=_4B05416A-81AD-4EFF-9A12-84612309E1AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-2

Hi

On 31 Oct 2012, at 13:57, Ola Andersson A wrote:

> Yes, I suppose that would allow for a few interesting possibilities. =
;-)
>=20
> An improvement would be to make it configurable in OTP apps where to =
find the included drivers.=20
> application:set_env could be used for that purpose.
> Of course it's probably not realistic to implement this change in =
every OTP app with C drivers.
>=20
> Any other ideas?

There's nothing to stop applications from doing the same workaround =
you're already using. If a common library added support for this, then =
everyone could share the same code to achieve it as well. One thing we =
discussed on the erlware mailing list when this idea was being knocked =
around was using .ez as one of the distribution formats. Certainly =
https://github.com/hyperthunk/rebar_dist_plugin supports this packaging =
method, although that plugin may not work with the latest version of =
rebar as I've not had time to bring it up to date. Now that rebar is =
moving properly over to semver, it'll be easier to manage that sort of =
thing.

> /OLA.=20
>=20
>> From: Tim Watson
>>=20
>> I think you'll find that constraint is enforced by the=20
>> operating system, rather than the erlang runtime. If=20
>> operating systems allowed you to dynamically load a library=20
>> from a process address space, that would open up a massive=20
>> security hole.
>>=20
>> On 31 Oct 2012, at 12:59, Ola Andersson A wrote:
>>=20
>>> Hi,
>>>=20
>>> I've been experimenting a little with escripts including=20
>> code archives for test purposes.
>>> It's a really useful feature that seems to work nicely at=20
>> least this far.
>>>=20
>>> The only stumbling block I have seen is when an application=20
>> included in the archive uses C drivers.
>>> When the path (code:priv_dir(App)) provided to e.g.=20
>> erl_ddll points into a code archive it will result in an error.
>>>=20
>>> I fixed it with a hack that extracted the driver to a temp=20
>> directory and patched the app to read the driver from the=20
>> temp directory and then remove it.
>>> Not something I would use in production code.=20
>>>=20
>>> Are there any plans to add the possibility to load a driver=20
>> directly from an archive?
>>>=20
>>> BR
>>> /OLA.
>>>=20
>>>> -----Original Message-----
>>>> From: erlang-questions-boun...@erlang.org
>>>> [mailto:erlang-questions-boun...@erlang.org] On Behalf Of Joe=20
>>>> Armstrong
>>>> Sent: den 30 oktober 2012 18:34
>>>> To: Andrew Berman
>>>> Cc: Erlang
>>>> Subject: Re: [erlang-questions] Turning rebar into a=20
>> package manager
>>>>=20
>>>> On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong <erl...@gmail.com>=20=

>>>> wrote:
>>>>> On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman
>>>> <rexx...@gmail.com> wrote:
>>>>>> I come from the Java world and I'm sorta blown away that Erlang=20=

>>>>>> doesn't have something comparable to JAR files, which work
>>>> just fine.
>>>>>=20
>>>>> Well it does actually - but this is not stunning well documented.
>>>>>=20
>>>>> In the manual page for code there is a section entited
>>>>>=20
>>>>> LOADING OF CODE FROM ARCHIVE FILES
>>>>=20
>>>> My mail got sent before I'd completed it ...
>>>>=20
>>>> programs like rebar use these features
>>>>=20
>>>> /Joe
>>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Everyone needs to
>>>>>> agree on a standard for which to package the applications.=20
>>>> JARs are
>>>>>> just zips of class files with config files, so why not=20
>> start there=20
>>>>>> and just have a zip file with the BEAMs and priv directory with=20=

>>>>>> configs.  Then we need erl to be able to read these zip
>>>> files and use
>>>>>> them as libraries without having to unzip them.  I think
>>>> we need to
>>>>>> just start simple and then evolve over time if we need to.
>>>>>>=20
>>>>>> --Andrew
>>>>>>=20
>>>>>> On Tue, Oct 30, 2012 at 4:08 AM, Tim Watson=20
>>>>>> <watson.timo...@gmail.com>
>>>>>> wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 30 Oct 2012, at 09:41, Ignas Vy=B9niauskas wrote:
>>>>>>>=20
>>>>>>>> On 10/23/2012 09:46 AM, Joe Armstrong wrote:
>>>>>>>>> The above link has an example command
>>>>>>>>>=20
>>>>>>>>>>> git fetch-pack --include-tag -v=20
>>>>>>>>>>> g...@github.com:hyperthunk/gitfoo.git
>>>>>>>> refs/tags/lager-0.9.4
>>>>>>>>=20
>>>>>>>> Wouldn't --depth=3D1 make it even better? Do we need all of the=20=

>>>>>>>> history here?
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Indeed we do not, though I've not tried that. Someone
>>>> also mentioned
>>>>>>> to me offline (a while ago) that they were concerned
>>>> about using git
>>>>>>> as a backend rather than adopting something that is not only=20
>>>>>>> distributed but actually has mirrors in place, e.g., apt/yum or=20=

>>>>>>> whatever.  Stashing things using git simply seemed like a
>>>> *free* way
>>>>>>> to get started when I was first looking at it.
>>>>>>>=20
>>>>>>> So, I'm fairly sure we're not going to figure out a way
>>>> to do this
>>>>>>> that pleases everybody. And *even* if the package=20
>> management and=20
>>>>>>> distribution problem was neatly solved, there would be
>>>> cases where
>>>>>>> you might actually
>>>>>>> *want* source code dependencies instead. Another reason
>>>> we looked at
>>>>>>> git was because once you've built everything, if you're=20
>> resolving=20
>>>>>>> dependencies from a central location (like $HOME/repo or
>>>> whatever)
>>>>>>> then you've got to deploy them as a snapshot each time
>>>> they're built
>>>>>>> and so on. This stuff actually gets quite involved - using say=20=

>>>>>>> maven, which is actually very good at managing this, it=20
>> can still=20
>>>>>>> make the development process over complicated at times.
>>>>>>>=20
>>>>>>> Take an example project: RabbitMQ. You're building
>>>> multiple projects
>>>>>>> that depend on each other, and the bug you're fixing
>>>> involves making
>>>>>>> changes to three different components, each of which
>>>> lives in its own repository.
>>>>>>> How're you going to figure out which projects need to=20
>> be built if=20
>>>>>>> they're all completely discrete by the time they go into the=20
>>>>>>> repository? Of course its easy to solve dependencies with
>>>> make and
>>>>>>> rebar will compile *including* dependencies by default,
>>>> which goes a
>>>>>>> long way to making this situation workable in practise.
>>>>>>>=20
>>>>>>> Of course what Joe is really talking about is the ability
>>>> to install
>>>>>>> *other people's work* for which you have absolutely no=20
>> (or maybe=20
>>>>>>> just very
>>>>>>> little) interest in the source code. I typically don't=20
>> care how a=20
>>>>>>> particular bit of cowboy or webmachine or whatever work,
>>>> as long as
>>>>>>> it does I just ignore it.
>>>>>>>=20
>>>>>>> And this problem cannot be *that hard* to solve,=20
>> because you know=20
>>>>>>> what - stuff like rubygems/bundler is really damn useful, as it=20=

>>>>>>> PyPI. I'm sure the node thing is great, though I've=20
>> never looked.
>>>>>>> Even OCaml Godi comes in useful and despite the vitriol I
>>>> hear about it, cabal+hackage is invaluable.
>>>>>>> Point is, these things make it easy to get stuff done,
>>>> thought they
>>>>>>> have gaps, flaws and whatnot - they still add a lot of value.
>>>>>>>=20
>>>>>>> Oh and BTW if someone does come up with a system to do
>>>> this, then it
>>>>>>> *should* just be packaged as a rebar plugin, as there's
>>>> no need to
>>>>>>> change rebar at all in order to override things like these.
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>> Tim
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> erlang-questions mailing list
>>>>>>> erlang-questi...@erlang.org
>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> erlang-questions mailing list
>>>>>> erlang-questi...@erlang.org
>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>=20
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questi...@erlang.org
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>=20
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questi...@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>=20


--Apple-Mail=_4B05416A-81AD-4EFF-9A12-84612309E1AB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)

iF4EAREIAAYFAlCRMA0ACgkQzpZnPFKwjIwlIwD+L/NY9Da8ruTO0KrisxVRxZU8
KJGAkkaKeAXyBqkuLUAA/25dImlrF2iOzywkK9FpBFpbQF5RHyas6rUIJ8gEFKhL
=Jx8c
-----END PGP SIGNATURE-----

--Apple-Mail=_4B05416A-81AD-4EFF-9A12-84612309E1AB--

--===============7266185332185684313==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--===============7266185332185684313==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
