Re: [145141] trunk/dports/python
> On Jan 27, 2016, at 3:57 PM, Andrew Fernandes> wrote: > > I think that's to be expected, for a port that hasn't been added to the > portindex yet. > > Oh - so lint gives different (and incomprehenible) output that changes > whether or not the port is in the index. Yeesh. > > No prob, committing a fix now. I’m also fixing the license issue. r145179 Well, lint was accurately telling you that your port py-pyinstaller has a dependency on py27-pyinstaller (which was added by the python 1.0 portgroup), and that no port named py27-pyinstaller exists in the portindex. lint didn't know that your new unindexed port included the definition for the py27-pyinstaller port. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [145141] trunk/dports/python
> On Jan 27, 2016, at 4:24 AM, Andrew Fernandes> wrote: > > MacPorts interprets the license field as a space-separated list of valid > license names. > > Ah, I vaguely remember that. I had simply copied the license field from the > original Portfile in #42693. > > But that didn’t cause the issue - I checked. >> +python.versions 27 33 34 35 >> > > Doesn't the python.versions line have to be outside this block? > > Yes, that’s what I’ve done before and that’s what all the other python ports > do. Setting python.versions is what causes the python 1.0 portgroup to create the subports. If it's inside an "if {${name} ne ${subport}}" block, it can never get executed, and the subports can never get created, because at the time the if statement is evaluated no subports exist yet, so at that point ${name} will always eq ${subport}. > However, if the line is outside the block - like every other port - I get a > “port lint” error that “py27-pypyinstaller is an unmet dependency” which I > simply don’t understand. I think that's to be expected, for a port that hasn't been added to the portindex yet. You can either add it to the portindex (by running the portindex command in the dports directory as the correct user), or just ignore it and check it again later after it's been committed. > Linting with a subport specified gives me no error. > > The only way I could get rid of it - and I spent a lot of time trying and a > lot of time googling, and a lot of time looking at other ports - was to move > the python.versions block inside the subport-check block. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [145141] trunk/dports/python
On Jan 26, 2016, at 13:50, adfernan...@macports.org wrote: > > Revision > 145141 > Author > adfernan...@macports.org > Date > 2016-01-26 13:50:47 -0800 (Tue, 26 Jan 2016) > Log Message > > new port: py-pyinstaller 3.1 closes #42693 > Added Paths > > trunk/dports/python/py-pyinstaller/ > trunk/dports/python/py-pyinstaller/Portfile > Diff > > Added: trunk/dports/python/py-pyinstaller/Portfile (0 => 145141) > > > --- trunk/dports/python/py-pyinstaller/Portfile > (rev 0) > +++ trunk/dports/python/py-pyinstaller/Portfile 2016-01-26 21:50:47 UTC > (rev 145141) > @@ -0,0 +1,31 @@ > +# $Id: Portfile 114324 2013-12-05 08:44:51Z ryandes...@macports.org $ > + > +PortSystem 1.0 > +PortGroup python1.0 > +PortGroup github1.0 > + > +namepy-pyinstaller > +version 3.1 > + > +fetch.type git Why do you need fetch.type git? > +github.setuppyinstaller PyInstaller ${version} v > + > +platforms darwin > +supported_archs noarch > +maintainers openmaintainer adfernandes > +description converts (packages) Python programs into stand-alone > executables > +long_description${description} > +license GPL license with a special exception which allows to use > PyInstaller to build and distribute non-free programs (including commercial > ones) MacPorts interprets the license field as a space-separated list of valid license names. You should probably only list licenses known to the port_binary_distributable.tcl script. You can add notes about the license in a portfile comment. > +homepagehttp://www.pyinstaller.org/ > + > +if {${name} ne ${subport}} { > + > +python.versions 27 33 34 35 Doesn't the python.versions line have to be outside this block? > +livecheck.type none > + > +} else { > +livecheck.type regex > +livecheck.url ${homepage} > +livecheck.regex "The latest stable release of PyInstaller is > (\\d+(?:\\.\\d+)*)" > +} ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev