Defork and namechange to get compliance against Cisco DevNet policies.
falkowich opened this issue · 11 comments
After an suggestion to publish this library in the Cisco DevNet community I have started a discussion with Github Support to defork from the original forks. And mpenning had no concerns about that » discussion here
But the libraryname is sadly to generic today to get it published in DevNet, so there if we shall publish it there the repo must change name. Perhaps to something like easy like iselibrary, iselib or suggestions. All the names I can come up with is.. perhaps not so enterprisy. :)
Like SNISEL (SuperNextgenerationISELibrary) :D
Any Ideas about namechange, reponame and such. Pls comment or reach out to me in a DM .
Plan as of 2021-10-20..
- contact github support about this.
- defork with the help of github support
- rename repository to pyise-ers
- rename module to pyiseers
- Start with the PR's
- Recommit the package on PyPI as pyise-ers
--
Regards Falk
I think it’s important to keep a name that will come up when searching for ISE on GitHub and PyPI. So even though I like your suggestion for SNISEL, I don’t think it’s very verbose or easy to search for.
iselib is a good suggestion. More options isn’t always helpful, but id suggest pyise.
Aren't there other ISE APIs aside from ERS? I've only used the ERS API, but I see documentation on a monitoring API. I was thinking that ISE-ERS-API-PyLib makes sense. It has all of the relevant information in the name.
That would be painful to import in your code 😉
pyiseers and pip install pyise-ers maybe
ise-ers-pylib then? The "API" bit was redundant
I agree that it's good to indicate that the package is Python. In the context of PyPI it's not necessary, that is implied, but it's helpful in Cisco DevNet where there could be a comparable library written for any other language. On that note, is there a similar library? If so, what is it called?
Regarding name length, I've never known the length of the package name to cause significant injury. :D In my opinion, the more descriptive the name is, the better (within reason). There are plenty of packages with longish names, Flask-JWT-Extended comes to mind. That's an example of the need for the name. Flask-JWT is JWT for Flask and Flask-JWT-Extended is a version with some sort of extended features. It's all described in the name, we don't need to consult the documentation to determine that.
Oh, thanks for all the suggestion and ideas!
I really liked @jifox suggestion tho. pyise-ers it's short, simple and descriptive.
Is it confusing to have the old import name the same "ise", perhaps it get's really confusing with that.
So it's better to do full rename with pyiseers and the pypy name pyise-ers?
Reading up on https://www.python.org/dev/peps/pep-0423/#how-to-rename-a-project
It's a lot of thing to get right, so that nobody gets left out in the cold..
--
Regards Falk
Well, I have procrastinated this long enough now..
So I will work on this to get the defork, name-change and pr's included with the beginning today.
The plan is to:
- defork with the help of github support
- rename module to pyiseers
- Recommit the package on PyPI as pyise-ers
- Start with the PR's
It's the plan atleast.. But as always..
No plan survives contact with the enemy.
Prussian Field Marshal Helmuth von Moltke the Elder
--
Regards Falk
Defork - done.
Next step, rename..
After some reading up it seems that github will forward the old reponame to the new name:
https://github.community/t/how-long-does-github-forward-renamed-moved-repos/582
And after some testing it seems to work really good.
This will happen tomorrow, is the plan atleast.
There are two PR's that I need some feedback on before manually merging.
I'm going to continue with the PyPi packages tomorrow and hopefully push pyise-ers 0.2 to PyPI then.
After this, all the chaos with renaming can be left behind.
And normal PR's and commits can start over..
It was a much bigger endeavor than I though to make this defork and rename.
And I really hope that I haven't made anyone feel angry when I messed up the PR's.
I really tried to keep everything as much possible to the history of the manual PR's.
--
Kind Regards Falk
Ok, this should now be finished.
The new package is:
https://pypi.org/project/pyise-ers/
This "nightmare" should now be done :)