Created attachment 146803 [details] test port log
Created attachment 146804 [details] test port log
Is there supposed to be a new port patch here Jingfen? :)
Created attachment 146872 [details] new shar file
(In reply to Kubilay Kocak from comment #3) > Is there supposed to be a new port patch here Jingfen? :) Sorry, wrong mouse click maybe. Thank you.
Is it possible for you to provide this as an SVN diff? It will help others review the patch more conveniently Thanks!
Created attachment 146874 [details] shar file update uses python ... and maintainer
Created attachment 146875 [details] portlint -AC output
Created attachment 146878 [details] svn diff
Created attachment 146879 [details] svn diff same 146878 content, but load from file, not paste it seems the paste one can only show plain text
Created attachment 146912 [details] 2nd updated shar file diff use suffix
Created attachment 146913 [details] 3rd update correct tab alignment
Created attachment 146914 [details] 3rd shar file correct alignment of tab.
GH_PROJECT is unnecessary, it defaults to ${PORTNAME} in Mk/bsd.sites.mk already :)
(In reply to Kubilay Kocak from comment #14) > GH_PROJECT is unnecessary, it defaults to ${PORTNAME} in Mk/bsd.sites.mk > already :) Will remove GH_PROJECT for all my new ports, except one: seafile-gui. The naming of original project is a little bit misleading. Seafile can have different front end of clients: desktop application, mobile apps, and web browser. Seafile's real client is part of seafile port. For the other ports, if their port names are as same as GH_PROJECT, I will remove the latter.
Created attachment 147235 [details] shar file target commit clean out .svn directory
The only problem I see with this is the tabs are messed up in the makefile (most should be 2 tabs, I see most at 3 though) Promoting to patch-ready pool
This was another one that I didn't realize was already assigned to python a couple of months ago. I'll take it as well.
Is this port really necessary? version 0.6 hasn't been in ports since 2012: http://www.freshports.org/www/py-djblets/ why does www/seahub need such an old version, and can it be patched to use the current version?
(In reply to John Marino from comment #19) > Is this port really necessary? > version 0.6 hasn't been in ports since 2012: > http://www.freshports.org/www/py-djblets/ > > why does www/seahub need such an old version, and can it be patched to use > the current version? I don't have the reason, too. During the porting procedure, I originally use the current version, because I know I have create sufficient numbers of ports. I don't remember the exact error that I encounter, it should be related to gunicorn. With the current version, it can not pass seahub.sh start (early stage). Till current 3.1.7 version, the server package release still specially packed with the old version of this. When I move to work on its next version, I will try again. My guess is that they have some fundamental code based on some deprecated API from this, or they can find some special work-around from the old version, which blocks new version.
(In reply to Jingfeng Yan from comment #20) > I don't have the reason, too. During the porting procedure, I originally > use the current version, because I know I have create sufficient numbers of > ports. I don't remember the exact error that I encounter, it should be > related to gunicorn. With the current version, it can not pass seahub.sh > start (early stage). Till current 3.1.7 version, the server package release > still specially packed with the old version of this. The only "gunicorn" I see in ports is py-gunicorn, which I think is what you are talking about, but it is at version 18.0 ! > When I move to work on its next version, I will try again. My guess is that > they have some fundamental code based on some deprecated API from this, or > they can find some special work-around from the old version, which blocks > new version. I would like you to take another look at the issue and see if we can find a way not to bring this port back. Perhaps the author of the software that needs if (if it does need it) can suggest a patch or other solution.
(In reply to John Marino from comment #21) > (In reply to Jingfeng Yan from comment #20) > > I don't have the reason, too. During the porting procedure, I originally > > use the current version, because I know I have create sufficient numbers of > > ports. I don't remember the exact error that I encounter, it should be > > related to gunicorn. With the current version, it can not pass seahub.sh > > start (early stage). Till current 3.1.7 version, the server package release > > still specially packed with the old version of this. > > The only "gunicorn" I see in ports is py-gunicorn, which I think is what you > are talking about, but it is at version 18.0 ! > > > When I move to work on its next version, I will try again. My guess is that > > they have some fundamental code based on some deprecated API from this, or > > they can find some special work-around from the old version, which blocks > > new version. > > I would like you to take another look at the issue and see if we can find a > way not to bring this port back. Perhaps the author of the software that > needs if (if it does need it) can suggest a patch or other solution. Hmm... I am trying now, and something start to be back in my mind. It seem the "funny" thing start from https://svnweb.freebsd.org/ports/head/www/py-djblets/Makefile?revision=371040&view=markup Based on its 0.7.28 egg (I assume that we are using py27), requires.txt: Django>=1.4.8,<1.5 django-pipeline==1.2.24 feedparser>=5.1.2 PIL pytz Which requires to install django1.4. The seahub web site requires min version of django is 1.5 (or higher). When I using current version of py-djblets in freebsd port, I have to remove all things that are using django15. Then, I did this before: I am trying to find a version djblets that support django15. I start to search higher version (normal sense I think) to see which version support django15. The last version in 0.7.x series is still django1.4. Then, I jump to 0.8.x series. The first and latest version of 0.8.x djblets give me: Django>=1.6.5,<1.7 ... It is quite odd. Let us consider in this way. There is another project using freebsd current py-djblets, its django should be in 1.4 series. We can not simply move it to another djblets version series (like 0.8.x). If the same port name move to 0.8.x series, it requires existing user carefully update their project to django1.6+. It could be some trouble. At that time, and maybe you will have similar question, where its support for django1.5. Maybe "never"... I search backward in the list. I found that its 0.6.x has a boundary that it requires Django>=1.1.1 PIL At this point, there is no conflict with django 1.5. My point could be like this kind of port (djblets), it is such tightly bind to django, could it be better to keep its version series? For example, we have django14, 15, 16, 17. But djblets only have one.
To be honest, I not that knowledgeable about the python part of the tree and I'm not comfortable making a decision about it on my own. I am adding python@ back to this ticket so we can get some direction from there. My feeling is that we want to avoid using a legacy port like this, and go through the effort to make sure it's not needed. But maybe python has better ideas or don't made having legacy djblets. Python@, can you review this PR and give advice?
or don't made having legacy djblets => or don't *mind* having legacy djblets.
(In reply to John Marino from comment #24) > or don't made having legacy djblets => > or don't *mind* having legacy djblets. Thank you for your time to read thru the long explanation. I understand your concern. I will spend sometime to see whether I can make it work by using django14 based on current djblets version. Or, we wish python side experts can give some guidelines. Python itself has its pkg and distribution system. The complex dimensions include python version, and pkg version, and pkg dependencies. I would like to learn how FreeBSD port system handles this in long term. Some packages do need have different version coexist. However, I don't whether this one belong to this range.
TL;DR Why not drop www/py-djblets and www/reviewboard until these problems are sorted out for higher impact python ports? As the only package the depends on www/py-djblets is www/reviewboard, is www/reviewboard of sufficient value as packaged for ports to justify its existence vs a pointer to a playbook to deploy reviewboard in a virtualenv? Granted, neither www/py-djblets nor www/reviewboard are packaged on pypi by the upstream author such that 'pip install reviewboard==version' actually works. Supporting python based web applications, I found there was more value in allowing the developers control over the pure python modules used rather than depending on native packages. Having native packages for python modules was much more useful for hard to build modules like PIL, long to build modules like scipy and numpy, and modules with tight coupling to native libraries (ldap, databases, ssl), or used by low level tools like ansible. A quick conversation with the upstream developer for these packages to put the source on pypi, and deprecating these ports on FreeBSD would be the least effort to provide the most usability. Revisit it when we have reasonable mechanisms for providing a python package for multiple versions of python.
(In reply to chris.dukes.aix from comment #26) > TL;DR Why not drop www/py-djblets and www/reviewboard until these problems > are sorted out for higher impact python ports? > > > As the only package the depends on www/py-djblets is www/reviewboard, is > www/reviewboard of sufficient value as packaged for ports to justify its > existence vs a pointer to a playbook to deploy reviewboard in a virtualenv? > > Granted, neither www/py-djblets nor www/reviewboard are packaged on pypi by > the upstream author such that 'pip install reviewboard==version' actually > works. > > Supporting python based web applications, I found there was more value in > allowing the developers control over the pure python modules used rather > than depending on native packages. > > Having native packages for python modules was much more useful for hard to > build modules like PIL, long to build modules like scipy and numpy, and > modules with tight coupling to native libraries (ldap, databases, ssl), or > used by low level tools like ansible. > > A quick conversation with the upstream developer for these packages to put > the source on pypi, and deprecating these ports on FreeBSD would be the > least effort to provide the most usability. Revisit it when we have > reasonable mechanisms for providing a python package for multiple versions > of python. Thank you for your explanation and comments. I have observed that some python ports already have different versions. For example, django-pipelines. I did quick try for using django14, and django16. The results are negative, both hot internal server error. I checked the seafile, they are pushed from django14 to django15 in mid of 2013, which took quite some efforts. When I use django14, I have not found out where is exact error because the application current log file did not show the exact error. I am hesitating to debugging it further. For using django16, extra python port efforts are required, including - django-pipelines 1.3.23+ - djblets 0.8.12 (can not port directly, only manually install) - pillowfight 0.2 In such case, I would suggest doing similar way as django-pipelines, which suggest keeping the 0.6 version. I check the Linux side port for this djblets. Debian system only carries 0.5 version (named python-django-djblets), and discontinue to have further version. The RPM for FC seems to have all the versions, but I don't know much of that system how they maintain dependencies (I thought they just build native and repackage the py modules).
I don't know anything about python (and I kind of like that way), but Chris Dukes seems to be saying it's optional and recommends not using it. Assuming that's what he actually said, then I don't understand Jingfeng Yan's next comment. For my part, I am only concerned about bug 193135 which is blocked by this. If we can build seahub without djbets altogether, that sounds good to me.
(In reply to John Marino from comment #28) > I don't know anything about python (and I kind of like that way), but Chris > Dukes seems to be saying it's optional and recommends not using it. You don't need to know squat about python. You do need to know the basics of package depdencies and the best practices of deploying python applications with dependencies that are not met by the packages provided by the operating system. As of the last time I updated my ports tree, seahub was not in it. *IF* it was, I'd suggest you chat with the port maintainer for it. The basics. You need djblets. You do not need a FreeBSD package for djblets. Typical behavior for deploying a python based web stack is to use 'virtualenv' to create an area for all/most of the dependencies that does not change the python modules installed system wide. Take a read through https://virtualenv.pypa.io/en/latest/ and http://virtualenvwrapper.readthedocs.org/en/latest/ They are in ports as devel/py-virtualenv and devel./py-virtualenvwrapper In addition a web stack usually makes use of something like a Makefile or a pip requirement file. Read more about a pip requirements file at https://pip.readthedocs.org/en/1.1/requirements.html. Looking at https://github.com/haiwen/seahub The author did include a requirements file for pip. Unfortunately the Djblets==0.6.14 requirement does not reference something that is in the index pip searches by default. My suggestion on your next steps are 1) Request that this bug be closed. You do not need Djblets packaged for FreeBSD. 2) Work out how to create a virtualenv and activate it. 3) Use pip and the requirements file to install most of the packages in the virutalenv. You may need to comment out the Djblets line. 4) Scour the web for the downloads for Djblets, download the version indicated in the requirements file and follow the instructions for building that manually. You'll do that in the virtualenv as well. When you find the seahub requirementsfile is wrong... take that discussion up with the seahub developer. As it stands, this port of Djblets exists as a convenience for the maintainer of the www/reviewboard package. If you can use it as is, great. If not... your back to learning about packaging dependencies and best practices for an app framework... or hiring someone to do the work. > > Assuming that's what he actually said, then I don't understand Jingfeng > Yan's next comment. > > For my part, I am only concerned about bug 193135 which is blocked by this. > If we can build seahub without djbets altogether, that sounds good to me. And to repeat my earlier statement. You need Djblets. You do not need Djblets packaged for FreeBSD. This port of Djblets exists to support www/reviewboard.
(In reply to chris.dukes.aix from comment #29) > (In reply to John Marino from comment #28) > > I don't know anything about python (and I kind of like that way), but Chris > > Dukes seems to be saying it's optional and recommends not using it. > > You don't need to know squat about python. You do need to know the basics > of package depdencies and the best practices of deploying python > applications with dependencies that are not met by the packages provided by > the operating system. > As of the last time I updated my ports tree, seahub was not in it. > *IF* it was, I'd suggest you chat with the port maintainer for it. > > The basics. > You need djblets. > You do not need a FreeBSD package for djblets. > > Typical behavior for deploying a python based web stack is to use > 'virtualenv' to create an area for all/most of the dependencies that does > not change the python modules installed system wide. > Take a read through https://virtualenv.pypa.io/en/latest/ and > http://virtualenvwrapper.readthedocs.org/en/latest/ > They are in ports as devel/py-virtualenv and devel./py-virtualenvwrapper > > In addition a web stack usually makes use of something like a Makefile or a > pip requirement file. Read more about a pip requirements file at > https://pip.readthedocs.org/en/1.1/requirements.html. > > > Looking at > https://github.com/haiwen/seahub > The author did include a requirements file for pip. > Unfortunately the > Djblets==0.6.14 > requirement does not reference something that is in the index pip searches > by default. > > My suggestion on your next steps are > 1) Request that this bug be closed. You do not need Djblets packaged for > FreeBSD. > 2) Work out how to create a virtualenv and activate it. > 3) Use pip and the requirements file to install most of the packages in the > virutalenv. You may need to comment out the Djblets line. > 4) Scour the web for the downloads for Djblets, download the version > indicated in the requirements file and follow the instructions for building > that manually. You'll do that in the virtualenv as well. > > When you find the seahub requirementsfile is wrong... take that discussion > up with the seahub developer. > > > As it stands, this port of Djblets exists as a convenience for the > maintainer of the www/reviewboard package. If you can use it as is, great. > If not... your back to learning about packaging dependencies and best > practices for an app framework... or hiring someone to do the work. > > > > > > Assuming that's what he actually said, then I don't understand Jingfeng > > Yan's next comment. > > > > For my part, I am only concerned about bug 193135 which is blocked by this. > > If we can build seahub without djbets altogether, that sounds good to me. > > And to repeat my earlier statement. > You need Djblets. > You do not need Djblets packaged for FreeBSD. > This port of Djblets exists to support www/reviewboard. Okay. I will see how I can change seahub to make it fit it. AS LONG AS it is clarified that FreeBSD port system does not want to carries the duplication of PyPI, I will treat those existing freebsd pkgs with multiple versions as EXCEPTIONS. :) If they ARE, we will try not to fall in those category. One question, do all the files that are installed into virtualenv pointed directory need to be tracked from freebsd port/pkg system?
(In reply to chris.dukes.aix from comment #29) > And to repeat my earlier statement. > You need Djblets. > You do not need Djblets packaged for FreeBSD. If djblets-06 is needed for seahub in FreeBSD (which can't be committed until this is sorted) it has to be ports in FreeBSD. The exception is if seahub adds djblets-06 as one if its distfiles and builds it in the workdir at the same time as seahub. Maybe this is what you mean by "virtualenv", but this virtualenv has to work within ports without using the network during the build phase. > If not... your back to learning about packaging dependencies and best practices for an app framework... or hiring someone to do the work. Not me. I just commit ports to the tree when its ready. I just wanted python@ to say the *legacy* port should or should not be in the tree.
(In reply to John Marino from comment #31) > (In reply to chris.dukes.aix from comment #29) > > And to repeat my earlier statement. > > You need Djblets. > > You do not need Djblets packaged for FreeBSD. > > If djblets-06 is needed for seahub in FreeBSD (which can't be committed > until this is sorted) it has to be ports in FreeBSD. The exception is if > seahub adds djblets-06 as one if its distfiles and builds it in the workdir > at the same time as seahub. Maybe this is what you mean by "virtualenv", > but this virtualenv has to work within ports without using the network > during the build phase. > > > > If not... your back to learning about packaging dependencies and best practices for an app framework... or hiring someone to do the work. > > Not me. I just commit ports to the tree when its ready. I just wanted > python@ to say the *legacy* port should or should not be in the tree. Hehe, I know it is not "you" (Marino). Never take it personally. Otherwise, I will feel that I am the nut. :) Some wording sounds not very friendly. I have finished using other way to install all the python dependencies. The virtualenv idea is right direction, but it is heavy-weight, and seahub release directory layout could be change a lot. So, I twist the seahub Makefile by borrowing the idea of virtualenv. So, we don't need this this port any more. I will try to close this issue. If I can not, could anyone help to close it. Thanks to all the reviewers for your efforts and suggestion.