Date: Sat, 15 Nov 2014 16:51:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 193135] [NEW PORT] www/seahub: Seafile web server front end Message-ID: <bug-193135-13-33CTIgYeSE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193135-13@https.bugs.freebsd.org/bugzilla/> References: <bug-193135-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193135 --- Comment #32 from Jingfeng Yan <yan_jingfeng@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193135-13-33CTIgYeSE>