Enot - Erlang package manager and deploy tool (+ answers on the questions)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Enot - Erlang package manager and deploy tool (+ answers on the questions)

Valery Tikhonov
Hi,

As promised, I have done renaming the tool. And now it is called 'Enot' [yenot] - that is raccoon in Russian.
My appology for not being answering the questions before - I was extremely busy with my personal stuff and renaming in general. So further in letter you'll see links on updated everything :) and answers on most questions.


Here are the updated links:
https://github.com/comtihon/enot - client
https://github.com/comtihon/enot_auto_builder - server
https://enot.justtech.blog/ - site
and updated articles:
https://justtech.blog/2018/01/07/create-erlang-service-with-enot/
https://justtech.blog/2018/02/11/erlang-service-easy-deploy-with-enot/

The GiHhub application and it's pip package are also renamed to enot.

Now I'll try to answer your questions:
First, Enot is not just another build system with new configuration format (eh, we already have two), but It is an easy deploy tool. You prepare your installation instructions and every user can install your package
via "enot install ..." CLI command. That's the main idea: to have something comparable with Python's pip.
Also I tried my best to design modern tool, similar to what they have in Java and Python worlds.
I took the best:
* prebuilt deps [Maven, Pip]. Now all CI/docker builds will be much faster
* an easy deploy [Pip].
* multiple environment configuration [Java]. See https://github.com/comtihon/enot/blob/master/docs/templating.md#appsrc-advanced-templates for more details.
* automatic name/version fill in at app.conf and relx.conf. Yes, I think that  manual handling of versions and constants is a little bit outdated and not practical. Especially, when you have to modify multiple files. 

Second, I believe Json coniguration is better for devOps, but if you don't want to learn it: use rebar or erlang.mk config - Enot understands them as well.

Third, there were some questions about security. I've added document here https://github.com/comtihon/enot/blob/master/docs/packaging_and_security.md
Main idea is: nobody can upload prebuilt package to EnotHub. You can only ask Enot Build Server to fetch sources from GitHub and build package.
Also, do you really use third-party github deps in production? I beleive not. So just fork dep you need, add it to EnotHub and use. Enot was designed to be fork-compatible. 

If your company is big enough to afford private git (gitlab), artifactory/nexus, ets. you can just run your private Enot Build server and switch all Enot clients to it to gain even more security.

As for cryptography package checks - I also find it important and I'll add it in a few weeks (still a little bit busy).

Many thanks to people who advocate me and my appologies to people who felt hurt.

I hope nothing will stop you to use this tool at work now :).

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Enot - Erlang package manager and deploy tool (+ answers on the questions)

Francesco Cesarini (Erlang Solutions)

Hi all,

I want to take a moment to thank Valery and everyone else working on Enot for listening and completing the name change. A special shutout goes to Fred and everyone else who tried to stop the outrage about our community and one another. The wide response snowballed pretty quickly and was less about the original post; this has only confirmed that what we do as a community make sense and is needed, but is also observed by others! Let's not allow this to shadow the hard work many have done to get to where we are today.

Get inspired by Sarah Allen keynote titled Language Encodes Wisdom which sums up not only where we are, but where we should be heading:

https://www.youtube.com/watch?v=_PdcGptErsY&t=1s

There is still loads to be done and we do hope many of you will not get discouraged but instead want to fuel the future of Erlang and inspire more people to join us. Our first goal? To welcome ideas, opinions, and outlooks as many as there are people creating this community free of harassment where there is reciprocal respect.

Francesco

On 18/02/2018 21:21, Valery Tikhonov wrote:
Hi,

As promised, I have done renaming the tool. And now it is called 'Enot' [yenot] - that is raccoon in Russian.
My appology for not being answering the questions before - I was extremely busy with my personal stuff and renaming in general. So further in letter you'll see links on updated everything :) and answers on most questions.


Here are the updated links:
https://github.com/comtihon/enot - client
https://github.com/comtihon/enot_auto_builder - server
https://enot.justtech.blog/ - site
and updated articles:
https://justtech.blog/2018/01/07/create-erlang-service-with-enot/
https://justtech.blog/2018/02/11/erlang-service-easy-deploy-with-enot/

The GiHhub application and it's pip package are also renamed to enot.

Now I'll try to answer your questions:
First, Enot is not just another build system with new configuration format (eh, we already have two), but It is an easy deploy tool. You prepare your installation instructions and every user can install your package
via "enot install ..." CLI command. That's the main idea: to have something comparable with Python's pip.
Also I tried my best to design modern tool, similar to what they have in Java and Python worlds.
I took the best:
* prebuilt deps [Maven, Pip]. Now all CI/docker builds will be much faster
* an easy deploy [Pip].
* multiple environment configuration [Java]. See https://github.com/comtihon/enot/blob/master/docs/templating.md#appsrc-advanced-templates for more details.
* automatic name/version fill in at app.conf and relx.conf. Yes, I think that  manual handling of versions and constants is a little bit outdated and not practical. Especially, when you have to modify multiple files. 

Second, I believe Json coniguration is better for devOps, but if you don't want to learn it: use rebar or erlang.mk config - Enot understands them as well.

Third, there were some questions about security. I've added document here https://github.com/comtihon/enot/blob/master/docs/packaging_and_security.md
Main idea is: nobody can upload prebuilt package to EnotHub. You can only ask Enot Build Server to fetch sources from GitHub and build package.
Also, do you really use third-party github deps in production? I beleive not. So just fork dep you need, add it to EnotHub and use. Enot was designed to be fork-compatible. 

If your company is big enough to afford private git (gitlab), artifactory/nexus, ets. you can just run your private Enot Build server and switch all Enot clients to it to gain even more security.

As for cryptography package checks - I also find it important and I'll add it in a few weeks (still a little bit busy).

Many thanks to people who advocate me and my appologies to people who felt hurt.

I hope nothing will stop you to use this tool at work now :).


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Enot - Erlang package manager and deploy tool (+ answers on the questions)

Lloyd R. Prentice-2
In reply to this post by Valery Tikhonov
Hi Valery,

This looks to be a very valuable contribution to the Erlang community. I like the new name. 

I hope you post a thorough tutorial on the web to demonstrate it’s use cases and uses.

All the best,

Lloyd

Sent from my iPad

On Feb 18, 2018, at 4:21 PM, Valery Tikhonov <[hidden email]> wrote:

Hi,

As promised, I have done renaming the tool. And now it is called 'Enot' [yenot] - that is raccoon in Russian.
My appology for not being answering the questions before - I was extremely busy with my personal stuff and renaming in general. So further in letter you'll see links on updated everything :) and answers on most questions.


Here are the updated links:
https://github.com/comtihon/enot - client
https://github.com/comtihon/enot_auto_builder - server
https://enot.justtech.blog/ - site
and updated articles:
https://justtech.blog/2018/01/07/create-erlang-service-with-enot/
https://justtech.blog/2018/02/11/erlang-service-easy-deploy-with-enot/

The GiHhub application and it's pip package are also renamed to enot.

Now I'll try to answer your questions:
First, Enot is not just another build system with new configuration format (eh, we already have two), but It is an easy deploy tool. You prepare your installation instructions and every user can install your package
via "enot install ..." CLI command. That's the main idea: to have something comparable with Python's pip.
Also I tried my best to design modern tool, similar to what they have in Java and Python worlds.
I took the best:
* prebuilt deps [Maven, Pip]. Now all CI/docker builds will be much faster
* an easy deploy [Pip].
* multiple environment configuration [Java]. See https://github.com/comtihon/enot/blob/master/docs/templating.md#appsrc-advanced-templates for more details.
* automatic name/version fill in at app.conf and relx.conf. Yes, I think that  manual handling of versions and constants is a little bit outdated and not practical. Especially, when you have to modify multiple files. 

Second, I believe Json coniguration is better for devOps, but if you don't want to learn it: use rebar or erlang.mk config - Enot understands them as well.

Third, there were some questions about security. I've added document here https://github.com/comtihon/enot/blob/master/docs/packaging_and_security.md
Main idea is: nobody can upload prebuilt package to EnotHub. You can only ask Enot Build Server to fetch sources from GitHub and build package.
Also, do you really use third-party github deps in production? I beleive not. So just fork dep you need, add it to EnotHub and use. Enot was designed to be fork-compatible. 

If your company is big enough to afford private git (gitlab), artifactory/nexus, ets. you can just run your private Enot Build server and switch all Enot clients to it to gain even more security.

As for cryptography package checks - I also find it important and I'll add it in a few weeks (still a little bit busy).

Many thanks to people who advocate me and my appologies to people who felt hurt.

I hope nothing will stop you to use this tool at work now :).
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions