On 2022-01-23 17:50:21, Omar Polo wrote:
>
> Thim <t...@cederlund.de> writes:
>
> > Hi Stuart,
> >
> > On 2022-01-23 14:25:17, Stuart Henderson wrote:
> >> On 2022/01/23 10:52, Thim wrote:
> >> > Hi Omar,
> >> >
> >> > On 2022-01-23 09:34:21, Omar Polo wrote:
> >> > > Thim <t...@cederlund.de> writes:
> >> > > >
> >> > > > Regarding those missing libraries that are optionals; I was thinking 
> >> > > > of
> >> > > > adding them but then I came to the conclusion that if tremc is the 
> >> > > > only
> >> > > > program using them there's no point to it really. No need to add 
> >> > > > stuff
> >> > > > that won't be used elsewhere.
> >> > >
> >> > > I think it's fine to at least give it a try to package those if the
> >> > > added functionality is useful.  I'm *personally* not that much
> >> > > interested in seeing the location of peers, but think that pyperclip
> >> > > could be useful.
> >> >
> >> > Very well. Pyperclip should be considered a optional dependency then.
> >> > Since this is a python package the typical GNU configure isn't used so I
> >> > am a bit confused as to how I would add this to the Makefile.
> >> > Porter's handbook nor the bsd.port.mk(5) manpage seem to cover this.
> >> >
> >> > >  - python programs usually don't have the "py-" prefix or FLAVORS.
> >> > >    They're just for python libraries.
> >> >
> >> > I may be wrong here but adding a hint of clipboard support via pyperclip 
> >> > in
> >> > the pkg/DESCR is the right move? Or is the better option to give the
> >> > user a message upon installation via pkg/MESSAGE?
> >>
> >> You could mention it in pkg/DESCR. I think few people will read it
> >> though. pyperclip is tiny, it wouldn't hurt to set it as a RUN_DEPENDS
> >> anyway.
> >>
> >> MESSAGE is better reserved for things which are really really
> >> important, otherwise people won't read those either.
> >>
> >
> > You're probably right. I've added it to RUN_DEPS in tremc and I
> > have made a port for pyperclip. Both tarballs are attached.
>
> GH_COMMIT is seldomly used.  Sometimes is inevitable, but if upstream
> releases a stable version, I think it's better to use it.  In particular
> for python stuff that's on pypi, you can create the port using portgen:
>
>       % portgen py pyperclip
>
> it will generate the port in /usr/ports/mystuff/pypi/py-pyperclip.  It's
> not perfect of course, but it gets few things right and it's (maybe?)
> easier to adjust what it creates rather than writing something from
> scratch.
>
> (portgen, like some other ports related helper programs, lives in
> /usr/ports/infrastructure/bin.)

Right, both tremc and pyperclip haven't released in a while which I
chose to pull from the latest commit.

Thanks for the tip regarding portgen.

>
> Also, I'd put it in the sysutils category instead of devel, but i guess
> either is fine.
>
> (i think for tremc using the latest commit is fine because there have
> been a number of improvements from the last tagged release and the
> project doesn't seem highly active.)
>
> > I assume that it is okay to have both of these ports in one mail thread?
> > Since the latter is a library, it won't do much on its own.
>
> I think that's fine :)
>
> > I did notice that pyperclip have tests in the setuptools.py file but I
> > couldn't get them all to work properly. It seems that it passes 10 tests
> > and fails another 10, either way pyperclip seems to be working just
> > fine.
>
> Using the version from pypi the tests doesn't even start.  I'm not a
> python dev and I'm not sure what's going on, but I'd avoid NO_TEST since
> some test are actually present.  NO_TEST is set only for ports with no
> regression suite, not for ports with an empty or failing one.

I'm not a python developer either but I have used tremc on other systems before
which is why I wanted to make a working port for it.

I actually had to force the language module to run the test with the
following line in the Makefile:

MODPY_PYTEST_ARGS = tests/test_pyperclip.py

> > Let me know what you think.
>
> The tarballs were actually tarbombs!

Sorry but thanks for a good laugh. I haven't heard that slang in a while :)

> Copying from tremc with M works here too.  I'm reattaching both ports
> (with pyperclip generated from portgen.)

Excellent, all good here as well. Both *tarballs* are attached and I have
added myself as the maintainer for py-pyperclip.


Br,

Thim Cederlund

Attachment: py-pyperclip.tar.gz
Description: GNU Zip compressed data

Attachment: tremc.tar.gz
Description: GNU Zip compressed data

Reply via email to