איתור וטיפול בפורקים של ספריות צד ג'

[Meir Kriheli]

היי,

יש מספר forks לחבילות צד ג' שמצויינים ב-buildout.cfg. כדי להלחם ב-bit rot ולנקות את הנדרש להתקנה, הכנתי רשימה שלהם ומצבם מול upstream והקיים ב-PyPI.

עבור חלק מהם המצב לא כך כך ברור (מדוע נדרש פורק). ריכזתי את הממצאים בגיליון הבא:
https://docs.google.com/spreadsheet/ccc?key=0Asw8o8275YNmdGdQRW12aGk1R3JJLV9xQ1lWelFxTHc

יש גם באג פתוח לזה:
https://track.nsa.co.il/issues/3728

האם בעלי הפורקים יכולים לעבור על הרשימה ולהאיר במענה להודעה זאת או בבאג הנ"ל אודות נחיצות/אי דיוקים ?

תודה רבה
--

Meir Kriheli
http://meirkriheli.com

[Amir More]

django-tastypie is me.

they have a bug that throws an exception when developing with the DummyCache.

I sent a pull request but they still haven't responded to it :/

django-annotatetext is the backend for the existing annotations - this will be removed once we migrate to the new annotations (although that might take a while)

2012/12/4 Meir Kriheli <mkri...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Open Knesset Developers" group.
To unsubscribe from this group, send email to oknesset-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Meir Kriheli]

Thanks for expanding on it

Regarding tastypie, IMO we can implement our own which extends CahceThrottle and handles DummyCache case. In case we'll do it, it's safe to assume that we can go with the upstream ?


Regarding django-annotatetext, can you assess how much if the changes are folded upstream, if at all ?

Thanks

2012/12/4 Amir More <hab...@gmail.com>

[Meir Kriheli]

If implemented a simple workaround for the DummyCache issue:
https://github.com/hasadna/Open-Knesset/commit/3bdab3936e874bb442fd2ca9f69dfb1213ce1936

Changed the buildout to use upstream tastypie.

Any comments regarding other packages mentioned in the spreadsheet ?

Cheers

[Meir Kriheli]

s/^if/I've

[Meir Kriheli]

Hi,

I'd like to move the forked personal repos to hasadna's one (thanks to Benny for the permissions on the repo), any objections ?

Cheers

[Gardenofwine]

Which means ill stop using /gardenofwine/open-knesset-mobile,

And start using (as an admin) /hasadna/open-knesset-mobile?

Written with a virtual keyboard.

[Meir Kriheli]

No, that's an application.

I'm talking about the forks of 3rd party packages which are required to develop and deploy OpenKnesset (listed in the spreadsheet mentioned in the 1st message of this thread).

It means that hasadna's repo will maintain those forks and will be used for installations and dev environments (via virtualenv/pip, etc).

Cheers

[Alon Levy]

+1, I assume you mean via git submodules. We will need to add something like
git submodule init
git submodule update

to the buildout process.

Another thought: we could package it as well (for debian/fedora/arch), that's going the other route.

Alon Levy

[Amir More]

github doesn't support git submodules :(

[Meir Kriheli]

Not via submodules. Hasadna should be considered upstream for those forks

Example: needed to change some things in setup.py for a couple of forks (django-annotatetext and django-activity-stream forks of Ofri and Benny), don't want to fork and set my, yet another,  personal fork as the source for the packages in buildout.cfg/requirements.txt.

Those should be under hasadna's umbrella, considered our upstream and installed from there (as proper python packages).

Packaging won't help too much, as:

• We need to cater windows and OS X devs as well.
• Those are unofficial forks of packages, distros won't accept them into the package repos (and we don't want to maintain our own distro repos).

Cheers

On Wed, Dec 12, 2012 at 12:47 PM, Alon Levy <alon...@gmail.com> wrote:

[Amir More]

+1

[Alon Levy]

On Wed, Dec 12, 2012 at 12:56 PM, Meir Kriheli <mkri...@gmail.com> wrote:

Not via submodules. Hasadna should be considered upstream for those forks

Example: needed to change some things in setup.py for a couple of forks (django-annotatetext and django-activity-stream forks of Ofri and Benny), don't want to fork and set my, yet another,  personal fork as the source for the packages in buildout.cfg/requirements.txt.

Those should be under hasadna's umbrella, considered our upstream and installed from there (as proper python packages).

Packaging won't help too much, as:

• We need to cater windows and OS X devs as well.

Of course this cannot help those platforms, but why should it keep us from doing it for this platform?
 

• Those are unofficial forks of packages, distros won't accept them into the package repos (and we don't want to maintain our own distro repos).

This depends on what you decide to patch, there are patches in all distros that are distro specific. This needs to be looked at on a per package basis. To be honest, this is true regardless of this conversation - we should not be carrying patched upstreams unless we have to - if there is an equivalent solution inside our code base, it may be preferable.
 

--
Alon Levy

[Meir Kriheli]

Hi.

On Wed, Dec 12, 2012 at 1:14 PM, Alon Levy <alon...@gmail.com> wrote:

On Wed, Dec 12, 2012 at 12:56 PM, Meir Kriheli <mkri...@gmail.com> wrote:

Not via submodules. Hasadna should be considered upstream for those forks

Example: needed to change some things in setup.py for a couple of forks (django-annotatetext and django-activity-stream forks of Ofri and Benny), don't want to fork and set my, yet another,  personal fork as the source for the packages in buildout.cfg/requirements.txt.

Those should be under hasadna's umbrella, considered our upstream and installed from there (as proper python packages).

Packaging won't help too much, as:

• We need to cater windows and OS X devs as well.

Of course this cannot help those platforms, but why should it keep us from doing it for this platform?
 

It shouldn't of course, however what should keep us from doing it, is:

• Spreading our scarce resources thin
• Won't help that much since:
• Those will be re-installed any way into virtualenv/buildout environments
• We're becoming dependant on distro's packaged versions (e.g.: Ubuntu 12.04, the LTS which will probably used on servers, carries Django 1.3.1, we're on Django 1.4, for smaller packages the situation is even messier).
  

As a result we won't gain anything of substance packaging it.
 

• Those are unofficial forks of packages, distros won't accept them into the package repos (and we don't want to maintain our own distro repos).

This depends on what you decide to patch, there are patches in all distros that are distro specific. This needs to be looked at on a per package basis. To be honest, this is true regardless of this conversation - we should not be carrying patched upstreams unless we have to - if there is an equivalent solution inside our code base, it may be preferable.
 

Yep, that would be ideal and  was my first reaction as well. Those I can switch to upstream already are (colored green in the spreadsheet).

Alas, reality strikes. Those projects were forked longed time ago (usually 2-3 years), and no proper patches were sent upstream, so doing it now is quite messy and time consuming.

Adding insult to the injury is the fact that some of those upstream project had no new releases nor meaningful activity for a long time, some were abandoned, some without proper PyPI releases and needed to be installed directly from their repo's branch and the list goes on.

Taking it into consideration, leaves us with a non-ideal middle ground, but workable one.

Cheers

 

[Alon Levy]

On Wed, Dec 12, 2012 at 1:44 PM, Meir Kriheli <mkri...@gmail.com> wrote:

Hi.

On Wed, Dec 12, 2012 at 1:14 PM, Alon Levy <alon...@gmail.com> wrote:

On Wed, Dec 12, 2012 at 12:56 PM, Meir Kriheli <mkri...@gmail.com> wrote:

Not via submodules. Hasadna should be considered upstream for those forks

Example: needed to change some things in setup.py for a couple of forks (django-annotatetext and django-activity-stream forks of Ofri and Benny), don't want to fork and set my, yet another,  personal fork as the source for the packages in buildout.cfg/requirements.txt.

Those should be under hasadna's umbrella, considered our upstream and installed from there (as proper python packages).

Packaging won't help too much, as:

• We need to cater windows and OS X devs as well.

Of course this cannot help those platforms, but why should it keep us from doing it for this platform?
 

It shouldn't of course, however what should keep us from doing it, is:

• Spreading our scarce resources thin
• Won't help that much since:
• Those will be re-installed any way into virtualenv/buildout environments
• We're becoming dependant on distro's packaged versions (e.g.: Ubuntu 12.04, the LTS which will probably used on servers, carries Django 1.3.1, we're on Django 1.4, for smaller packages the situation is even messier).
  

As a result we won't gain anything of substance packaging it.
 

• Those are unofficial forks of packages, distros won't accept them into the package repos (and we don't want to maintain our own distro repos).

This depends on what you decide to patch, there are patches in all distros that are distro specific. This needs to be looked at on a per package basis. To be honest, this is true regardless of this conversation - we should not be carrying patched upstreams unless we have to - if there is an equivalent solution inside our code base, it may be preferable.
 

Yep, that would be ideal and  was my first reaction as well. Those I can switch to upstream already are (colored green in the spreadsheet).

Alas, reality strikes. Those projects were forked longed time ago (usually 2-3 years), and no proper patches were sent upstream, so doing it now is quite messy and time consuming.

Adding insult to the injury is the fact that some of those upstream project had no new releases nor meaningful activity for a long time, some were abandoned, some without proper PyPI releases and needed to be installed directly from their repo's branch and the list goes on.

Taking it into consideration, leaves us with a non-ideal middle ground, but workable one.

Cheers

OK, Just took a look at the spreadsheet, cursory look only but I see the problems (loc would have been also interesting for anyone like me who might want to try tackling upstreaming anyway later), keep up the good work.

Alon