Thim <[email protected]> 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 <[email protected]> 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.)
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.
> Let me know what you think.
The tarballs were actually tarbombs!
Copying from tremc with M works here too. I'm reattaching both ports
(with pyperclip generated from portgen.)
Thanks
Omar Polo
> Br,
>
> Thim Cederlund
tremc.tar.gz
Description: Binary data
py-pyperclip.tar.gz
Description: Binary data
