Dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependencies

David Bjergaard
Hi All,

When I first started maintaining stumpwm, I was interested in knowing if people
were OK with extra dependencies in stumpwm.  This was before quicklisp was as
popular as it is now, and the build prescription didn't even mention it.

Things have changed now, and there have been a handful of contributions that
change the way stumpwm handles its internal loop.  There are also many, many
places where stumpwm re-invents the wheel for the sake of keeping dependencies
to a minimum.  The arguments for minimal dependencies are/were:
1. Less overhead for compiling (especially those unfamiliar with lisp development)
2. Less dependence on upstream changes that break their interface
3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
4. Lower dependencies make it easier for distro managers to package and ship
   stumpwm outside of quicklisp/compiling with make

Quicklisp clearly nullifies argument 1.  Argument 2 is still an issue.  I've
been told that argument 3 is also moot with quicklisp since libraries in
quicklisp are supposed to run in multiple flavors.  In practice I've had the
opposite experience with the gui libraries  I've looked at (qt and smoke, and
the freetype renderer).  

While I believe philosophically that we should only depend on sbcl (the most
popular flavor), others in the community disagree.  Therefore I have agreed that
the mainline stumpwm will keep the minimal dependency design requirement, and
that paulownia (stumpwm 2.0) will have a much looser policy.  

I bring this up because there have been requests to:
1. remove dependence on cl-ppcre
2. add dependence on bordeaux-threads and alexandria

I think it warrants a discussion since the landscape has changes so much in the
last 3-4 years.

    David

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies

Dimitri Minaev
On 11/01/2016 11:12 PM, David Bjergaard wrote:

> Hi All,
>
> When I first started maintaining stumpwm, I was interested in knowing if people
> were OK with extra dependencies in stumpwm.  This was before quicklisp was as
> popular as it is now, and the build prescription didn't even mention it.
>
> Things have changed now, and there have been a handful of contributions that
> change the way stumpwm handles its internal loop.  There are also many, many
> places where stumpwm re-invents the wheel for the sake of keeping dependencies
> to a minimum.  The arguments for minimal dependencies are/were:
> 1. Less overhead for compiling (especially those unfamiliar with lisp development)
> 2. Less dependence on upstream changes that break their interface
> 3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
> 4. Lower dependencies make it easier for distro managers to package and ship
>    stumpwm outside of quicklisp/compiling with make


Do you think it's feasible (both legally and technically) to include
well tested versions of the dependencies into the Stumpwm source tree?
Some extra efforts required from the maintainer will prevent dependency
bloat :)

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies

aaermolov
In reply to this post by David Bjergaard
Hi David,

Just curious, what is supposed to be used instead of cl-ppcre that way?

Alex

David Bjergaard <[hidden email]> writes:

> Hi All,
>
> When I first started maintaining stumpwm, I was interested in knowing if people
> were OK with extra dependencies in stumpwm.  This was before quicklisp was as
> popular as it is now, and the build prescription didn't even mention it.
>
> Things have changed now, and there have been a handful of contributions that
> change the way stumpwm handles its internal loop.  There are also many, many
> places where stumpwm re-invents the wheel for the sake of keeping dependencies
> to a minimum.  The arguments for minimal dependencies are/were:
> 1. Less overhead for compiling (especially those unfamiliar with lisp development)
> 2. Less dependence on upstream changes that break their interface
> 3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
> 4. Lower dependencies make it easier for distro managers to package and ship
>    stumpwm outside of quicklisp/compiling with make
>
> Quicklisp clearly nullifies argument 1.  Argument 2 is still an issue.  I've
> been told that argument 3 is also moot with quicklisp since libraries in
> quicklisp are supposed to run in multiple flavors.  In practice I've had the
> opposite experience with the gui libraries  I've looked at (qt and smoke, and
> the freetype renderer).  
>
> While I believe philosophically that we should only depend on sbcl (the most
> popular flavor), others in the community disagree.  Therefore I have agreed that
> the mainline stumpwm will keep the minimal dependency design requirement, and
> that paulownia (stumpwm 2.0) will have a much looser policy.  
>
> I bring this up because there have been requests to:
> 1. remove dependence on cl-ppcre
> 2. add dependence on bordeaux-threads and alexandria
>
> I think it warrants a discussion since the landscape has changes so much in the
> last 3-4 years.
>
>     David
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (463 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies

Alex Kost
In reply to this post by Dimitri Minaev
Dimitri Minaev (2016-11-02 11:16 +0400) wrote:

> On 11/01/2016 11:12 PM, David Bjergaard wrote:
>> Hi All,
>>
>> When I first started maintaining stumpwm, I was interested in knowing if people
>> were OK with extra dependencies in stumpwm.  This was before quicklisp was as
>> popular as it is now, and the build prescription didn't even mention it.
>>
>> Things have changed now, and there have been a handful of contributions that
>> change the way stumpwm handles its internal loop.  There are also many, many
>> places where stumpwm re-invents the wheel for the sake of keeping dependencies
>> to a minimum.  The arguments for minimal dependencies are/were:
>> 1. Less overhead for compiling (especially those unfamiliar with lisp development)
>> 2. Less dependence on upstream changes that break their interface
>> 3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
>> 4. Lower dependencies make it easier for distro managers to package and ship
>>    stumpwm outside of quicklisp/compiling with make
>
> Do you think it's feasible (both legally and technically) to include
> well tested versions of the dependencies into the Stumpwm source tree?
> Some extra efforts required from the maintainer will prevent dependency
> bloat :)

Oh no!  Bundling third-party libraries is awful, please don't do it!

--
Alex

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies

David Bjergaard
In reply to this post by aaermolov
Hi,

cl-ppcre is used in one place to parse the X11 display string.  That
functionality could be replaced with a specific solution rather than a regex.

That being said, cl-ppcre is used in a lot of the contrib modules that we ship,
so its probably better to keep it.

    David

[hidden email] writes:

> Hi David,
>
> Just curious, what is supposed to be used instead of cl-ppcre that way?
>
> Alex
>
> David Bjergaard <[hidden email]> writes:
>
>> Hi All,
>>
>> When I first started maintaining stumpwm, I was interested in knowing if people
>> were OK with extra dependencies in stumpwm.  This was before quicklisp was as
>> popular as it is now, and the build prescription didn't even mention it.
>>
>> Things have changed now, and there have been a handful of contributions that
>> change the way stumpwm handles its internal loop.  There are also many, many
>> places where stumpwm re-invents the wheel for the sake of keeping dependencies
>> to a minimum.  The arguments for minimal dependencies are/were:
>> 1. Less overhead for compiling (especially those unfamiliar with lisp development)
>> 2. Less dependence on upstream changes that break their interface
>> 3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
>> 4. Lower dependencies make it easier for distro managers to package and ship
>>    stumpwm outside of quicklisp/compiling with make
>>
>> Quicklisp clearly nullifies argument 1.  Argument 2 is still an issue.  I've
>> been told that argument 3 is also moot with quicklisp since libraries in
>> quicklisp are supposed to run in multiple flavors.  In practice I've had the
>> opposite experience with the gui libraries  I've looked at (qt and smoke, and
>> the freetype renderer).  
>>
>> While I believe philosophically that we should only depend on sbcl (the most
>> popular flavor), others in the community disagree.  Therefore I have agreed that
>> the mainline stumpwm will keep the minimal dependency design requirement, and
>> that paulownia (stumpwm 2.0) will have a much looser policy.  
>>
>> I bring this up because there have been requests to:
>> 1. remove dependence on cl-ppcre
>> 2. add dependence on bordeaux-threads and alexandria
>>
>> I think it warrants a discussion since the landscape has changes so much in the
>> last 3-4 years.
>>
>>     David
>>
>> _______________________________________________
>> Stumpwm-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel