* Re: Request to follow SemVer/mention it in homepage
2015-09-29 7:36 ` Eric Wong
@ 2015-09-29 7:46 ` Lin Jen-Shin (godfat)
2015-09-29 8:00 ` Pirate Praveen
2015-09-29 9:26 ` Jérémy Lecour
2 siblings, 0 replies; 12+ messages in thread
From: Lin Jen-Shin (godfat) @ 2015-09-29 7:46 UTC (permalink / raw)
To: Eric Wong; +Cc: Pirate Praveen, unicorn-public
On Tue, Sep 29, 2015 at 3:36 PM, Eric Wong <e@80x24.org> wrote:
> Pirate Praveen <praveen@debian.org> wrote:
[...]
>> It will help us a lot in maintain rails applications in debian. We
>> like to keep only one version of any app/lib in debian and if you can
>> guarantee Semantic Versioning rails apps using unicorn could declare a
>> looser dependency rather than upto the patch version. Now gitlab
>> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
>> following Semantic Versioning they could change it to ~> 4.8 and ~>
>> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
>> does not match ~> 4.8.3
>
> Tying a Rack app to unicorn is totally, completely wrong and defeats the
> point of Rack.
>
> Honestly, I could understand tying an app to thin with it's EM-specific
> API, but unicorn(!?!?) Even if an app isn't thread-safe, it should
> still work in passenger, thin, or puma/webrick configured for a
> single-thread...
I guess the issue is that people need to specify which server they're
using in their Gmefile when bundler is used to launch the application.
I don't think it's a good idea to bind to a specific version though.
Upgrading unicorn never breaks anything for me.
p.s. Personally I never liked the idea of semantic versioning either,
unless there's a clearly defined API like Rack's SPEC.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-29 7:36 ` Eric Wong
2015-09-29 7:46 ` Lin Jen-Shin (godfat)
@ 2015-09-29 8:00 ` Pirate Praveen
2015-09-29 19:36 ` Eric Wong
2015-09-29 9:26 ` Jérémy Lecour
2 siblings, 1 reply; 12+ messages in thread
From: Pirate Praveen @ 2015-09-29 8:00 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public
On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org> wrote:
>Pirate Praveen <praveen@debian.org> wrote:
>> Do you follow Semantic Versioning as defined by semver.org? If yes,
>> can you mention it on the homepage? If not, can you consider it?
>
>Maybe we follow semver...
>
>No, I'd rather not mention it on the homepage or be formally/officially
>bound to it (see below)
>
>I have considered it in the past, but decided against it...
>
>unicorn is on the verge of becoming 5.x:
>
>This is for internal changes which some weirdo projects (notably
>Rainbows!) rely on; but was never considered public API or marketed
>as such. I absolutely do not want people building server-specific
>apps when Rack exists.
Can you consider SemVer from 5.x?
>Rack will also hit 2.x soon, but regardless of incompatible changes
>in Rack, unicorn must remain compatible with both 1.x and 2.x for
>practical reasons.
>
>> It will help us a lot in maintain rails applications in debian. We
>> like to keep only one version of any app/lib in debian and if you can
>> guarantee Semantic Versioning rails apps using unicorn could declare
>a
>> looser dependency rather than upto the patch version. Now gitlab
>> defines unicorn ~> 4.8.3 and diaspora defines ~> 4.9.0 If you are
>> following Semantic Versioning they could change it to ~> 4.8 and ~>
>> 4.9 and 4.9.0 will satisfy both. Currently debian has 4.9.0 and it
>> does not match ~> 4.8.3
>
>Tying a Rack app to unicorn is totally, completely wrong and defeats
>the
>point of Rack.
>
>Honestly, I could understand tying an app to thin with it's EM-specific
>API, but unicorn(!?!?) Even if an app isn't thread-safe, it should
>still work in passenger, thin, or puma/webrick configured for a
>single-thread...
>
>
>Regardless of a formalities such as semver, I'll work to ensure unicorn
>can be compatible[1] with any Rack apps in Debian main.
>Heck, perhaps Rack 0.9.x still works (assuming the installed Ruby
>version supports it).
>
>Just let us know what real problems you find, they will be fixed.
If you can convince gitlab to declare ~> 4.8 and assure it will work with 4.9, that will solve the issue for now.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820
Also if you can help convinse diaspora upstream to declare a looser dependency, that will also help.
>Fwiw, Debian is my preferred platform and I can stay 100% within email
>with the Debian BTS + lists.
Glad to know.
>
>[1] I would never say unicorn is the best choice for all apps,
> but it should at least limp along with sufficiently loose
> definitions of "working", perhaps with hundreds of inefficient
> processes in some cases.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-29 8:00 ` Pirate Praveen
@ 2015-09-29 19:36 ` Eric Wong
2015-09-30 16:04 ` Pirate Praveen
0 siblings, 1 reply; 12+ messages in thread
From: Eric Wong @ 2015-09-29 19:36 UTC (permalink / raw)
To: Pirate Praveen; +Cc: unicorn-public
Pirate Praveen <praveen@debian.org> wrote:
> On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org> wrote:
> >Pirate Praveen <praveen@debian.org> wrote:
> >> Do you follow Semantic Versioning as defined by semver.org? If yes,
> >> can you mention it on the homepage? If not, can you consider it?
<snip>
> >I have considered it in the past, but decided against it...
> >
> >unicorn is on the verge of becoming 5.x:
> >
> >This is for internal changes which some weirdo projects (notably
> >Rainbows!) rely on; but was never considered public API or marketed
> >as such. I absolutely do not want people building server-specific
> >apps when Rack exists.
>
> Can you consider SemVer from 5.x?
Again, the answer is "no". I do not want people to depend on unicorn
providing a stable API of any sort. Even if in practice and history
it does: the config file directives and internal constant names
haven't changed at all in 5-6 years and there are no plans to change it.
> >Regardless of a formalities such as semver, I'll work to ensure unicorn
> >can be compatible[1] with any Rack apps in Debian main.
> >Heck, perhaps Rack 0.9.x still works (assuming the installed Ruby
> >version supports it).
> >
> >Just let us know what real problems you find, they will be fixed.
>
> If you can convince gitlab to declare ~> 4.8 and assure it will work
> with 4.9, that will solve the issue for now.
>
> See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820
That's not a real compatibility bug with unicorn itself. Again, it's
wrong of them to have a dependency on any Rack server at all.
> Also if you can help convinse diaspora upstream to declare a looser
> dependency, that will also help.
>
> >Fwiw, Debian is my preferred platform and I can stay 100% within email
> >with the Debian BTS + lists.
I am only doing plain-text email. I'm done with websites requiring
login + registration.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-29 19:36 ` Eric Wong
@ 2015-09-30 16:04 ` Pirate Praveen
2015-09-30 19:51 ` Eric Wong
0 siblings, 1 reply; 12+ messages in thread
From: Pirate Praveen @ 2015-09-30 16:04 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wednesday 30 September 2015 01:06 AM, Eric Wong wrote:
> Pirate Praveen <praveen@debian.org> wrote:
>> On २९ सप्टेंबर, २०१५ १:०६:५० [PM] IST, Eric Wong <e@80x24.org>
>> wrote:
>>> Pirate Praveen <praveen@debian.org> wrote:
>>>> Do you follow Semantic Versioning as defined by semver.org?
>>>> If yes, can you mention it on the homepage? If not, can you
>>>> consider it?
>
> <snip>
>
>>> I have considered it in the past, but decided against it...
>>>
>>> unicorn is on the verge of becoming 5.x:
>>>
>>> This is for internal changes which some weirdo projects
>>> (notably Rainbows!) rely on; but was never considered public
>>> API or marketed as such. I absolutely do not want people
>>> building server-specific apps when Rack exists.
>>
>> Can you consider SemVer from 5.x?
>
> Again, the answer is "no". I do not want people to depend on
> unicorn providing a stable API of any sort. Even if in practice
> and history it does: the config file directives and internal
> constant names haven't changed at all in 5-6 years and there are
> no plans to change it.
Can you mention the recommended way of adding unicorn in a Gemfile in
your home page?
gitlab and diaspora has unicorn in their Gemfile, for a user they want
gitlab or diaspora and they don't care if its using unicorn or puma or
passenger.
I need some kind of an official statement about compatibility which I
can show to projects like gitlab and diaspora, so they don't insist on
exact patch release of unicorn. I could patch the Gemfile, but that
adds extra burden on me as a maintainer which I'd like to avoid if
possible.
>>> Regardless of a formalities such as semver, I'll work to
>>> ensure unicorn can be compatible[1] with any Rack apps in
>>> Debian main. Heck, perhaps Rack 0.9.x still works (assuming
>>> the installed Ruby version supports it).
>>>
>>> Just let us know what real problems you find, they will be
>>> fixed.
>>
>> If you can convince gitlab to declare ~> 4.8 and assure it will
>> work with 4.9, that will solve the issue for now.
>>
>> See https://gitlab.com/gitlab-org/gitlab-ce/issues/2820
>
> That's not a real compatibility bug with unicorn itself. Again,
> it's wrong of them to have a dependency on any Rack server at all.
>
>> Also if you can help convinse diaspora upstream to declare a
>> looser dependency, that will also help.
>>
>>> Fwiw, Debian is my preferred platform and I can stay 100%
>>> within email with the Debian BTS + lists.
>
> I am only doing plain-text email. I'm done with websites requiring
> login + registration.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWDAf9AAoJEM4fnGdFEsIqYV0P/AmIFATrnxSF4V5Q5v05LT5G
LcVkXCzMhQYnPaVYwiAEi5JLGkiFw2r2Y5kWgF3WLynXHqWmUpGoNLEsG5tZG38V
109RYYKG5VgsGw6HlIoOwpy61MF9/d29+CRDXvLs0q7wc1/CbDEYqnhwLvKKOT9o
xZBD3bXsLuXiRl/BR8xk1q5fy4oS0rNnTU4MWcc8pEKU3KFE0xkXqA5WVS3ENShg
WLfqlUnll2SnQwyR1FzqFJws5OzejKpdNRZK1IOD1ivMd8aBVY25+0u6Q3o/2h/J
dW4ID9QV6R1fCtLybKqkI/fwljlKGs+shY+5lvUqE2KSYe8gwyHm6r1DslprzwM6
QhzLXqBtvDxSxX41sbcr12SoEt7poRztr+8gFXqni+iTkoljgsmODQMWX/ed/9O8
AekqfSrA//K1JfUpGKWHr1+UXhijHggYcKi0eoCJA2GH5ijLu5DIglEuGCQtthl9
z4/aI/na1M7goqBKw1Qtuxc/AHlBAkDcsott5n+4FIQInc5ooiyj54+Sek1AZNWw
/pp5F6z3axPgH3+h26Jf4W8OHl58gUeht9G7sl2j5GwMDkVSOtwlgwhLEYWdZ8Mw
pZcDXl/0VieD6LBFEh3N5MfkP+n3aYHrenCbsxRBh/jn6/+wczoUruNYl0SbSgUh
62qZ2q/7NgvHBdVPtXaB
=F2uT
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-30 16:04 ` Pirate Praveen
@ 2015-09-30 19:51 ` Eric Wong
2015-10-01 4:56 ` Pirate Praveen
0 siblings, 1 reply; 12+ messages in thread
From: Eric Wong @ 2015-09-30 19:51 UTC (permalink / raw)
To: Pirate Praveen; +Cc: unicorn-public
Pirate Praveen <praveen@debian.org> wrote:
> Can you mention the recommended way of adding unicorn in a Gemfile in
> your home page?
I'm not very knowledgeable about bundler, but app servers probably
should not be in any packaged Gemfile at all.
> gitlab and diaspora has unicorn in their Gemfile, for a user they want
> gitlab or diaspora and they don't care if its using unicorn or puma or
> passenger.
>
> I need some kind of an official statement about compatibility which I
> can show to projects like gitlab and diaspora, so they don't insist on
> exact patch release of unicorn. I could patch the Gemfile, but that
> adds extra burden on me as a maintainer which I'd like to avoid if
> possible.
"Official statements" do not have much weight behind them; history does.
They can look at the git history (especially that of manpages and
documentation) to see the only feature removals were for undocumented
cruft.
Personally, I intensely dislike "official" things; so people shouldn't
take what I (or anybody) writes as gospel.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-30 19:51 ` Eric Wong
@ 2015-10-01 4:56 ` Pirate Praveen
2015-10-01 11:18 ` Pirate Praveen
0 siblings, 1 reply; 12+ messages in thread
From: Pirate Praveen @ 2015-10-01 4:56 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public, Jonne Haß
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
[copying jhass, maintainer of diaspora]
jhass, they prefer email to issue tracker so I copied you here.
You can see the complete discussion here
http://bogomips.org/unicorn-public/560A31F1.3060608%40debian.org/t/#u
On Thursday 01 October 2015 01:21 AM, Eric Wong wrote:
> Pirate Praveen <praveen@debian.org> wrote:
>> Can you mention the recommended way of adding unicorn in a
>> Gemfile in your home page?
>
> I'm not very knowledgeable about bundler, but app servers probably
> should not be in any packaged Gemfile at all.
May be jhass can explain the rationale for adding unicorn to Gemfile
better.
>> gitlab and diaspora has unicorn in their Gemfile, for a user they
>> want gitlab or diaspora and they don't care if its using unicorn
>> or puma or passenger.
>>
>> I need some kind of an official statement about compatibility
>> which I can show to projects like gitlab and diaspora, so they
>> don't insist on exact patch release of unicorn. I could patch the
>> Gemfile, but that adds extra burden on me as a maintainer which
>> I'd like to avoid if possible.
>
> "Official statements" do not have much weight behind them; history
> does.
>
> They can look at the git history (especially that of manpages and
> documentation) to see the only feature removals were for
> undocumented cruft.
jhass, can we relax unicorn dependency to ~> 4.9?
> Personally, I intensely dislike "official" things; so people
> shouldn't take what I (or anybody) writes as gospel.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWDLz7AAoJEM4fnGdFEsIqN5MQAKEWGiI3IBfOYmquIplkG/7E
5gohMKsCDJlj6lgqaPIHzvekIW7ssNlxKv9cmeA/v+uNNCKZw6OEw4dmkfJHq5VV
mQ+bBCKkymTFR7ZrIWIs43D0E4To4Sf5LD6MpECiQI1MypFoy66rl0FqJR9PQcF0
nPqcI8LDEICePZwgPdeRrTrS4vCfr4U+BmQWuYovIjwAGEoslnNeblKE+q4LcnGu
09XWelo8eYL62EI6XB92KWCFx0isiEBGQK0PzLqZUbWz17Y7kNMxeAnfmPZQFoe5
4qI7SEtSusFU3OW2t6Eyj6/bh+hP7W2jtMnub+B+QBBUqjf50WV0p4FqUUXMzheS
wDJbtVdYNbNO4f6cWLMVGC18jOVzJw86luc+QoxptTCShku+gFROrkA4w+ciHpNk
2x92Z/S2ejYZlJKGhH97KqMe2gAKgikwYk2zgjSLtpxxrAPiE2nP3tX5KKOG7BNO
iUPdftzLD04oEr21QMb/gRpCEP0f8zsECK/vkpB4VjfjM9HhgEDJZzOfOTvHs04b
avILU6iTUQkSMcWhtdp8bxsifhD+sSjhThWbbMyomV9LdjVBf9gf3J4pzTALT5Rf
rc+V0Gf+dScHpSFMphY7Y7vKuS/PjKvLq1qD2rAsOtDVPDxVT99HsVTUUNR6lAY0
eHegzfNqE/oqHosK1dLN
=AglS
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-10-01 4:56 ` Pirate Praveen
@ 2015-10-01 11:18 ` Pirate Praveen
2015-10-01 19:06 ` Eric Wong
0 siblings, 1 reply; 12+ messages in thread
From: Pirate Praveen @ 2015-10-01 11:18 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
[dropping jhass]
He says "It's probably just conflicting opinion, distributing Ruby
applications to untrained people is still uncommon"
On Thursday 01 October 2015 10:26 AM, Pirate Praveen wrote:
> [copying jhass, maintainer of diaspora]
>
> jhass, they prefer email to issue tracker so I copied you here.
>
> You can see the complete discussion here
> http://bogomips.org/unicorn-public/560A31F1.3060608%40debian.org/t/#u
>
> On Thursday 01 October 2015 01:21 AM, Eric Wong wrote:
>> Pirate Praveen <praveen@debian.org> wrote:
>>> Can you mention the recommended way of adding unicorn in a
>>> Gemfile in your home page?
>
>> I'm not very knowledgeable about bundler, but app servers
>> probably should not be in any packaged Gemfile at all.
>
> May be jhass can explain the rationale for adding unicorn to
> Gemfile better.
jhass: "Adding unicorn to the Gemfile eases installation by taking a
step out of it, allows site local installation of it
(--path/--deployment) and ensures the right version so our
integrations (config/unicorn.rb, config/eye.rb, script/server) don't
break."
With debian packaging, our aim is to get a user setup an application
like gitlab or diaspora, just using the package manager they are
already familiar with. They don't have to know what language it is
written, what framework or application server or what database it is
using, all they are interested is the application specific configuration
.
How much compatibility we can expect for config/unicorn.rb?
>>> gitlab and diaspora has unicorn in their Gemfile, for a user
>>> they want gitlab or diaspora and they don't care if its using
>>> unicorn or puma or passenger.
>>>
>>> I need some kind of an official statement about compatibility
>>> which I can show to projects like gitlab and diaspora, so they
>>> don't insist on exact patch release of unicorn. I could patch
>>> the Gemfile, but that adds extra burden on me as a maintainer
>>> which I'd like to avoid if possible.
>
>> "Official statements" do not have much weight behind them;
>> history does.
>
>> They can look at the git history (especially that of manpages and
>> documentation) to see the only feature removals were for
>> undocumented cruft.
>
> jhass, can we relax unicorn dependency to ~> 4.9?
>
>> Personally, I intensely dislike "official" things; so people
>> shouldn't take what I (or anybody) writes as gospel.
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWDRZyAAoJEM4fnGdFEsIq+HsP/1T373t8YXTm0e+EAwJxcGaH
SpSdhDrZGcz9oI3vmwx8N1dX86/28hZzU5TEwi/xB4KN/Xzd+fZwTp1lpwTMcEI9
rSUPnknDo8FatT17fg6B99RmB30uIRbIgVgzfUIj30LL0bGC0ulVlVZEZ95jURb4
YVwXuxgRUH5gV7Ql/LpkBnnTni6kgy9Jsrq7ShaaxGNY2NsMrV3hAeN2aSuSJNU/
jUOZCjXzoDKdGS/pfdPTOdAHVSzKtnJ9cZhktBPbSmvHrJ0Zx7Di6zG8TJAQO+EG
n3qlR/ghke4MzNWIprVcqxH37ML6ww913UBCyVRGNOtU+c2/sEd+AlyIjBIzRK9n
Nq5jpcAd5doJHgfIesTxWSX4QhjH6XPqPpbMvIFEwHHpiv8lNi/+Rp5mTFAHiEJY
zEQCSOQmOBiLY56q/e/OVnK+L+6s9gCxYkynzsmgfrJ0HjBd9DNENMpKgboUj3sN
8I+CqerNq3h4lSvnAyb9pdUiAmSv+uD4aMXtgCltWlcC2cNQL51w6OKBO8+hKMuw
uKFihtyUkSD/51e4vmx5lVmz0+7vXPY1CyezbreX50V/zJcYMhJy0Cg42L+BGEWu
8lqrLxoCxua7j5p+hya1D0xuCvQ9eVKmfA2oXwJ7ChR6ZdACMfV6vn47UzYXIyBk
7HbtK7HFc7QVuC3Xg/e8
=JLvl
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-10-01 11:18 ` Pirate Praveen
@ 2015-10-01 19:06 ` Eric Wong
0 siblings, 0 replies; 12+ messages in thread
From: Eric Wong @ 2015-10-01 19:06 UTC (permalink / raw)
To: Pirate Praveen; +Cc: unicorn-public
Pirate Praveen <praveen@debian.org> wrote:
> With debian packaging, our aim is to get a user setup an application
> like gitlab or diaspora, just using the package manager they are
> already familiar with. They don't have to know what language it is
> written, what framework or application server or what database it is
> using, all they are interested is the application specific configuration
I suggest webrick. It's not bad nowadays with Ruby 2.x and is the only
standard server in Ruby. For out-of-the-box use, unicorn is probably
the worst possible default since it requires nginx.
> How much compatibility we can expect for config/unicorn.rb?
I assume you mean the Unicorn::Configurator class (in
lib/unicorn/configurator.rb). That won't change, it hasn't
changed since 2009 as I mentioned in:
http://bogomips.org/unicorn-public/20150929193627.GA7572%40dcvr.yhbt.net/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-29 7:36 ` Eric Wong
2015-09-29 7:46 ` Lin Jen-Shin (godfat)
2015-09-29 8:00 ` Pirate Praveen
@ 2015-09-29 9:26 ` Jérémy Lecour
2015-09-29 19:43 ` Eric Wong
2 siblings, 1 reply; 12+ messages in thread
From: Jérémy Lecour @ 2015-09-29 9:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Pirate Praveen, unicorn-public
On Tue, Sep 29, 2015 at 9:36 AM, Eric Wong <e@80x24.org> wrote:
> Tying a Rack app to unicorn is totally, completely wrong and defeats the
> point of Rack.
I completely agree with that statement.
However, having an app with hard dependency on a specific app server
is not the same a providing a default setup for a given app server.
For example, an app like Gitlab, Discourse or whatever might provide a
default good configuration for Unicorn, a set of optimisations in the
context of a Unicorn (pre/post fork instructions…) and have something
that works great out of the box, even if it's not restricted to
Unicorn.
Someone who would want to change to Passenger, Puma or else would have
to adapt the configuration and port the optimizations, but the app
would work the same as with Unicorn, without crippled features.
Someone who wouldn't change or tweak anything would have a good
setting by default.
--
Jérémy Lecour :
http://jeremy.wordpress.com - http://twitter.com/jlecour
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Request to follow SemVer/mention it in homepage
2015-09-29 9:26 ` Jérémy Lecour
@ 2015-09-29 19:43 ` Eric Wong
0 siblings, 0 replies; 12+ messages in thread
From: Eric Wong @ 2015-09-29 19:43 UTC (permalink / raw)
To: Jérémy Lecour; +Cc: Pirate Praveen, unicorn-public
Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
> On Tue, Sep 29, 2015 at 9:36 AM, Eric Wong <e@80x24.org> wrote:
> > Tying a Rack app to unicorn is totally, completely wrong and defeats the
> > point of Rack.
>
> I completely agree with that statement.
>
> However, having an app with hard dependency on a specific app server
> is not the same a providing a default setup for a given app server.
>
> For example, an app like Gitlab, Discourse or whatever might provide a
> default good configuration for Unicorn, a set of optimisations in the
> context of a Unicorn (pre/post fork instructions…) and have something
> that works great out of the box, even if it's not restricted to
> Unicorn.
Right, Debian has Recommends/Suggests: fields for soft dependencies; but
I still consider that overkill.
> Someone who would want to change to Passenger, Puma or else would have
> to adapt the configuration and port the optimizations, but the app
> would work the same as with Unicorn, without crippled features.
> Someone who wouldn't change or tweak anything would have a good
> setting by default.
Perhaps there could be per-server Debian packages such as:
gitlab-webrick (should be the default)
gitlab-puma
gitlab-passenger
gitlab-unicorn
...
Given unicorn has always required the use of nginx for exposure to
public clients, unicorn is perhaps the worst choice as a default
server for people unwilling to read documentation and edit config
files.
^ permalink raw reply [flat|nested] 12+ messages in thread