[Bug 193135] [NEW PORT] www/seahub: Seafile web server front end

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193135

--- Comment #32 from Jingfeng Yan <yan_jingfeng at yahoo.com> ---
(In reply to John Marino from comment #31)
> (In reply to Jingfeng Yan from comment #30)
> > Why reviewboard-1.7.22 requires djblets, then it get a specific version of
> > djblets.  If other application needs other version of djblets, why we can
> > not have a version of djblets for that app?
> 
> I think you are asking the wrong question.  The question is, why is seahub
> unable to use the latest version of djblets?  This makes seahub look bad IMO.
> 
> It's a bad situation.  I wanted to avoid the situation *IF POSSIBLE*.  If
> it's not possible, then fine, we bring back a legacy port.  This kind of
> thing is why I avoid python.
> 
> > That is why I am confused what is the policy for python pkg version port in
> > FreeBSD port system. Do I miss any important point from the other thread.
> 
> It's just good practice not to have multiple versions of the same port. 
> Avoid it where it's possible.  Sometimes it can't be avoided.  But I didn't
> want to make this call, I wanted the python@ team to give good advice.

(1)
The information that I gathered is that Djblets is tightly bind to version of
Django.  As I understand, if you select version of Django, then you have
specific version range of Djblets.  I can start to push Seahub developer to
move newer version of Django, but which version os Django will not be known
soon, and how long it take may not known.  So, we might have to have multiple
versions of Djblets.  The positive part is that we are introducing higher
versions, not back to legacy.  

However, if we look at the problem in other point of view: When updating
Djblets from 0.6 to current version in port system, if the old version  were
kept for Django 15, we would have seen the same result:  We have specific
version Djblets for specific Django version. So, the point is not to bring back
legacy version, but keep Django chain in complete. (The reason that I mentioned
Linux side Djblets naming in 193316, just gave some idea that it does have some
evidence Django and Djblets have some tight binding).
It does not mean anything wrong in that decision. But, Django 15 is still alive
in the port system, and we don't want to say everyone have to run the bleeding
version. 

I agree with you because we must be very careful to keep multiple version of
python packages (especially some old stuff) because it is a big headache thing
(python version, package version, ... that multiple-dimension problem will
stuff the port system).  So, I bring the problem whether we want to have
multiple versions, or it takes case by case.  If you think from keeping Django
framework complete, taking Djblets 0.6.14 back is not such bad, just another
special case.  

(2)
(FYI, Seahub was PUSHED from Django lower version to current version 15, we can
not not use Django14 related Djblets, which is 0.7.12 in system). The statement
in other thread:

- Seahub needs Djblets, not FreeBSD port.  

So, I move the dependencies into seahub to be handled by python setuptools and
place the django15, and Djblets0.6 under seahub place instead of global site. 
However, this way seems not be able to seperated dependency downloading and
installation (I am still learning whether it is possible, but not that bright
so far).  The current python package download happens in do-install stage. I
don't know whether these can happens on post-fetch stage (it could be very
odd).  In py-djbelts06 thread, it stressed that the users should have their
virtualenv to run stuff. For setting up virtualenv, it is not part of port
system. If FreeBSD port should not have Djblets, then it must be handled by the
users.  

(3)
Overall, I think the python side don't want to have it, I can not do it thru
do-install.  If placing setup.py running in fetch procedure is a bad hacking, I
have to say forget about the Django related dependencies.  We leave this part
to users' virtual env.  Seahub release package does not include anything about
Django ... It might be me that run too far.

-- 
You are receiving this mail because:
You are the assignee for the bug.