avoid conflict: consider renaming the project space and main binary

Is the feature related to a problem? Please describe.

As you may be aware, there is already a pwncat software which has already been packaged in multiple distros hence the other software blocks the namespace as well as the binaries. Forcing people to use a virtualenv instead of allowing easy installation via a package manager seems to be a shortcoming instead of a solution.

https://github.com/cytopia/pwncat https://pypi.org/project/pwncat/

This other software is already the single owner of the pwncat package space across those distros: https://repology.org/project/pwncat/versions

Feature Description

A perfect solution, as painful as it may sound, would be to rename the repository (github creates auto redirects) as well as rename the main pwncat binary to something that is not yet packaged in distros and pypi. It would be in my humble opinion very healthy for this awesome project top be able to get easily installed via various package managers across distros and Kali etc hence a rename would have more gain as disadvantages. A unique name will also make sure this software is found uniformly across different installation paths.

Potentially simply use pwncats? 😸

Thank you very much for your consideration. I know how painful this may sound, but I am a package maintainer and unfortunately I now can’t as much as i would love to package this piece of software.

cheers 😸

[calebstewart]

Totally on board for renaming the repository. That’s not an issue, but I don’t think I will do that until v0.5.0 is ready for release and/or released. In my mind, that just makes the most sense (making a hard switch will be less confusing as opposed to a gradual change).

Regarding short binary names, I totally get that, and I’m fine with dropping pc. Those names were originally chosen to mirror the various forms of netcat, but that’s obviously not a priority. Further, I don’t think many people use them. Based on another issue, I think pcat might have actually gotten accidentally dropped from setup.py during a previous cleanup merge, but that’s super easy to drop back in if we decide that it’s useful/good.

I’m not sure if you’re a Python developer or not (trying not to make assumptions here), but any recommendations on module naming scheme if we wanted to make a hard distinction between us and a possible future Cytopia module? We could make the name pwncat_cs which would be a valid Python module name. Underscores just feel aesthetically displeasing to my brain for module/library names when coding or interacting with applications.

Frankly, this entire conversation is based on aesthetics. In my mind, an ideal name (both binary and package name) is somewhere around 6-10 letters long with no dashes or underscores. That’s normally long enough to convey uniqueness and/or purpose but still short enough to not be frustrating to type without tab-completion.

If I’m being honest with myself, there’s nothing tying me to any form of the name pwncat at all. If people have other suggestions that are completely unrelated, I’m open to them. Making a big change like that now rather than later is probably good anyway.

Thank you very much for openly discussing solutions. I’m very happily looking forward to be the first distro that packages this awesome tool.

No problem, and thank you for bringing it up! If something is open source, it’s for the community. I’m open to whatever is feasible and will help the community! 👍

[anthraxx]

I think Caleb is registering pwncat-cs on PyPi and migrating to poetry See #149

Yes I’ve seen the pypi commit but that doesn’t really resolve the issue so far. The best would be if the project has the same name as well as the binary. This would solve that this project has a uniform name across distros that package it. The unique binary is a pre requirement for any packaging tho.

pwncat-cs would also be possible for the repo/project as well as the binary. I frankly just try to get this distributed and try to propose some ideas as help 🐱