Hi there!
I've spent some time working on DPPy and I now feel ok to reference it on PyPi.
However, the name dppy is already taken see dppy, but:
What can I do to make my DPPy project as the (or at least not void) dppy on PyPi ?
Btw, I've started testing the pypi pipeline on https://test.pypi.org/project/dppy-dpps/
Nobody can help? 馃啒
Hi there, still nobody to help ? 馃樋
According to PEP541, in order to transfer a project name, a project must first be determined to be abandoned:
- no activity from the owner on the project's home page (or no home page listed).
I could not determine a project home page.
- no releases within the past twelve months; and
The most recent release was 2018-08-01, which was only six months ago. In a strict interpretation of PEP 541, there are still six months to go before that criteria is met.
- owner not reachable (see Reachability above);
I have emailed the owner of the project using the only contact information we have. This contact information does not appear publicly. (Given the above dates, we can only ask politely if the owner is interested in releasing the name.)
In the meantime, there are a few other things to be considered:
- the candidate is able to demonstrate their own failed attempts to contact the existing owner;
Given no public contact information, that's a tough one.
- download statistics on the Package Index for the existing package indicate project is not being used; and
As noted, even though releases artifacts exist, both the wheel and sdist contain nothing more than an empty dppy/__init__.py. Download stats for the last 30 days show two requests from pip, 372 from bandersnatch and 35 from browsers and requests each.
- the candidate is able to demonstrate that the project suggested to reuse the name already exists and meets notability requirements;
- the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround;
Can you speak to these last two points?
Hi @jamadden, thanks you very much for this thorough answer!
Can you speak to these last two points?
- the candidate is able to demonstrate that the project suggested to reuse the name already exists and meets notability requirements;
I am a Ph.D. student whose topic of research is _Determinantal Point Processes_ with very used acronym DPPs and mostly code with Python, hence the name DPPy.
We've been working on the DPPy project for almost a year.
We've written an extensive documentation on ReadTheDocs and use Travis for CI.
A companion paper for the toolbox is already written for later submission to a Open Source Software track of a Machine Learning journal surch as JMLR-MLOSS
You can find the paper
In particular we would very much like to have a pip install DPPy available for the submission
- the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround;
I would argue again that
More and more people are becoming aware of this project and it would be very confusing not to provide a natural pip install DPPy and even misleading to end up downloading an empty project..
We feel the project mature enough to be put on PyPI, however:
We've been testing different names for the project on TestPyPi and removed them. The last one we came up with (yesterday) is DPPyPI but we are still not convinced that this is the best fit to not confuse current and future users 馃槙
In the meantime, there are a few other things to be considered:
- the candidate is able to demonstrate their own failed attempts to contact the existing owner;
Given no public contact information, that's a tough one.
Actually, I've tried to contact the Takayuki Yagi which would fit the most a Machine Learning guy but didn't get any answer
On linkedin, 2019-01-18 https://fr.slideshare.net/TakayukiYagi1?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview

By emial to [email protected] on 2019-01-17

Thank you very much for your consideration!
Hmm, I forgot about the Invalid Projects part of PEP 541:
A project published on the Package Index meeting ANY of the following is considered invalid and will be removed from the Index:
- project does not conform to Terms of Use;
- project is malware (designed to exploit or harm systems or users);
- project contains illegal content;
- project violates copyright, trademarks, patents, or licenses;
- project is name squatting (package has no functionality or is empty);
- project name, description, or content violates the Code of Conduct; or
- project is abusing the Package Index for purposes it was not intended.
The "project is name squatting (package has no functionality or is empty)" clause certainly seems to apply here too.
Interesting!
What is the next step then ?
Such cases are extremely rare. The vast majority of the 'PEP541' cases I've looked at which have been resolved have ultimately involved a willing transfer; the ones that are remain open are the cases without a clear-cut answer. I've done some data gathering and put out some hypotheses, but those are just my guesses and ultimately I think some of the more experienced PyPI admins (e.g., @ewdurbin @dstufft @di) would need to have a look and set a course of action. It may take same time.
Hi @jamadden @ewdurbin @dstufft @di!
Any update on this case ? 馃檪
Hi guys,
Next month, it will be 1 year since the dppy project is on PyPI without any activity.
Can we anticipate an action to make sure the name dppy is free again on PyPI on 08/01/2019 ?
Thanks in advance
Hi @jamadden @ewdurbin @dstufft @di
It's been exactly a year now that the void dppy project is squatting the name with absolutely no activity.
Can I now claim the name dppy, please ? 馃檨
Best regards,
Hi @guilgautier, what's your username on PyPI?
Hi @di,
Thanks for your reply!
I'm using the same user name: guilgautier
Done. Please note that you won't be able to make releases using versions 0.0.1, 0.0.2 or 0.0.3 as these were previously used.
Most helpful comment
Done. Please note that you won't be able to make releases using versions
0.0.1,0.0.2or0.0.3as these were previously used.