2.0.1 and 2.0.2 are not available on PyPI

[SylvainCorlay]

I am confused about the available releases of Cookiecutter. The last version available PyPI is 1.7.3 but I see commits, tags, and a changelog for version 2.0.1 and 2.0.2, and also no 2.0.0 tag or commit.

Are these tags meant to be pre-releases?

[gmelillo]

+1 on it. Also, the documentation is referring cookie-cutter v2 but cannot be installed by pip

[mabdullahadeel]

+1 on it. Also, the docs for 1.7.3 are also removed. So this is a weird situation. I was just trying private variables which I believe is supported by version >2.*. But I kept trying and was just about to open an issue related to that.

I think #1555 will resolve the issue.

[HosamAlmoghraby]

the versions 2.0.1 and 2.0.2 were tagged and deployed to the test repository of PyPI https://test.pypi.org/
it was just meant for testing, you can find it here: https://test.pypi.org/project/cookiecutter/

[egpbos]

Given #1642, would it make sense to automate deployment of tagged releases to main PyPI with a GitHub Action?

[dvzrv]

it was just meant for testing, you can find it here: https://test.pypi.org/project/cookiecutter/

Can you elaborate on what you mean by that? The tags denote a stable release (not a pre-release).
Currently it is completely unclear what to package for downstreams and whether those releases are even meant to be there.

@audreyfeldroy and @pydanny you seem to have created the last two stable releases. Can you please comment on this issue? This is a problem for downstreams trying to use cookiecutter (in packaging or otherwise). Thanks for your efforts on this project!

[mabdullahadeel]

it was just meant for testing, you can find it here: https://test.pypi.org/project/cookiecutter/

Can you elaborate on what you mean by that? The tags denote a stable release (not a pre-release). Currently it is completely unclear what to package for downstreams and whether those releases are even meant to be there.

@audreyfeldroy and @pydanny you seem to have created the last two stable releases. Can you please comment on this issue? This is a problem for downstreams trying to use cookiecutter (in packaging or otherwise). Thanks for your efforts on this project!

@dvzrv The things is pypi has two environments hosted on two different domains i-e pypi.org and test.pypi.org. The first one is for production releases and should not be messed up. For that reason, they provide sort of test environment to deploy your package. It works pretty much in a similar manner but does not meant to be used in production.

Let me know if you have any query.

[dvzrv]

For that reason, they provide sort of test environment to deploy your package. It works pretty much in a similar manner but does not meant to be used in production.

@mabdullahadeel Thanks for pointing that out. I guess the use case for the service becomes clear in its banner:

Warning You are using TestPyPI – a separate instance of the Python Package Index that allows you to try distribution tools and processes without affecting the real index.

It is meant to be used to test "distribution tools and processes". This does not mean it is meant to be used to publish prereleases (that's what semver is for). It is a test instance of pypi.org (of the service itself), to test tools such as poetry, pdm, etc. and the service itself.
At least judging from the information banner on https://test.pypi.org this does not entail using it for publishing stable releases, that by some undefined logic are deemed "not ready for production".

To cycle back on the 2.0.x releases:
The latest documentation points at 2.0.2 (which again, denotes a stable release according to semver), so the implication here is, that it is a stable release.

This makes me wonder why a prerelease version is not in use, if the current 2.0.x releases are not supposed to be used? Is this only because there were accidental releases?

The question remains: What are downstreams supposed to use? When will 2.0.x be made available on pypi.org?

[mabdullahadeel]

@dvzrv yeah you are right. The docs are updating just fine because readthedocs pick it from the master branch.

Maintainers are talking about the latest release but I guess they are not finding the adequate time and we need to respect that. I think the latest version will be out pretty soon.

[akaszynski]

When will 2.0.x be made available on pypi.org?

I’d really like to see the current stable release of cookiecutter on PyPI. There are several features and bug fixes that we need from the latest release, especially as it’s documented in the current release notes at readthedocs.

[jensens]

I do not get it, it would be totally fine to release alphas and betas and RCs to the real PyPI. I would not expect a final as something to be released on test.

I also dont get, why one releases a 2.0.1 as non-final, but maybe its only old me using semantic versioning these days.

Well, anyway, I would love to see a real release. I continue to test with current main branch, looks like its easier in my setup than with test-pypi (and yes, I know how to configure it, I just refuse it, because I consider this as the wrong way to do things).

[ferdnyc]

The release issues aren't just limited to PyPi. 2.0.1 and 2.0.2 weren't made releases on GitHub, either — there are tags, but they don't show up at https://github.com/cookiecutter/cookiecutter/releases which claims, as does the repo landing page, that the latest release is 1.7.3.

As a result of that (as well as their absence from PyPi), Linux distros are mostly still packaging 1.7.3 as the "latest release".

[ssbarnea]

There are only 4 people that can address this and they are all listed on https://pypi.org/project/cookiecutter/ -- what the project needs is a service account with manage (not owner) rights, and get the tokens added to the release environment configuration, the one at https://github.com/cookiecutter/cookiecutter/settings/environments/256223547/edit (only maintainers can access).

Sadly I do not have the credentials to that as my pypi account (ssbarnea) is not listed there.

@insspb @audreyfeldroy @hackebrot @pydanny Only one of you can help here. Would you be so kind to address current stuck situation?

[jorgepiloto]

Version 2.0.x solves the bug with cookiecutter private variables. If a package depends on cookiecutter 2.0.x:

cookiecutter @ git+https://www.github.com/cookiecutter/cookiecutter.git@2.0.2

The pakcage will not be allowed to be published on PyPI due to the following error:

Invalid value for requires_dist. Error: Can't have direct dependency

At least, a cookiecutter 2.0.1a1 or cookiecutter 2.0.2a1 could be provided in PyPI. This would allow users to still access cookiecutter 1.7.3 as the stable but solve at the same time previous dependency problem.

This project is amazing, thanks for all the time you devote to it @insspb, @audreyfeldroy, @hackebrot @pydanny. Wish to see those versions on PyPI soon! 🚀

[akaszynski]

I've released ansys-cookiecutter as a stop-gap measure to get the 2.0.2 package out. It's based on the GitHub tag 2.0.2, and I've also had to modify the version within setup.py.

All are free to use the package (of course), and I'll leave it up for as long as people use it. I'll post a deprecation warning within setup.py recommending to use the real cookiecutter package once it's released.

---

Also, I'd like to volunteer to help maintain this package. This is so we can at least get a release out the door and merge some of these minor PRs. Please let me know if I can help.

[ssbarnea]

To be honest, because I seen that all the calls remediate the release pipeline went unanswered for probably more than an year, I plan to drop cookiecutter use on molecule project.

I mentioned those 4 from pypi multiple times and nothing happened. Statistically is very unlikely that all of them missed all the notifications. I am sure they are busy, but keeping the "keys" is not ok either because is strangulating the project.

Setting a service account token on github release environment takes less than 5 minutes...

[akaszynski]

This is less than ideal, but shouldn't it be possible to scrape the token from secrets.PYPI_TOKEN? All you have to do is echo the first N characters and then echo the final (total characters - N). This way you can pull the secret off this repo.

If someone can add me as a maintainer with write access to this project (or admin, muhahahahahaha), I can do it.

[egpbos]

If you want to take over maintenance and we cannot reach the current maintainers, probably better to just fork.

[akaszynski]

If you want to take over maintenance and we cannot reach the current maintainers

All four can't be reached? Is this project then unmaintained?

[egpbos]

@ssbarnea, are you sure you don't have maintenance access to PyPI? I think @audreyfeldroy said (#1555 (comment)) that you had it. Perhaps she can grant you access again if you somehow lost it?

[jensens]

[alkatar21]

If you look at the contributions @audreyfeldroy and @insspb are inactive.
But @hackebrot and @pydanny are active. Actually it should be possible to give at least @ssbarnea just rights, so that there can be a release.
Then you can still look if there could be directly another with the current master and then you can take care of the maintaining.

Maybe someone can contact them on twitter. Maybe they respond there?

[jensens]

FYI: @ericof and I are are in the process of resolving this. Expect an official release within next week.

[HosamAlmoghraby]

FYI: @ericof and I are are in the process of resolving this. Expect an official release within next week.

Hello @jensens @ericof I am wondering about your plan for the next release!

To avoid work redundancy, I would like to mention here the PR #1638. In few words, because the release process was not clear and there was a lack of documentation, it was agreed with the project creator @audreyfeldroy that we replace the old building and publishing tools (wheels and setuptools) with poetry and add documentation for the release process, also adjusting the workflow ci. but then, because Audrey was not able to follow up, the PR was not merged and thus the release was not done... The PR is still waiting for 6 months, I hope it won't be ignored.

I would really like to be the release manager for the next release...

[jensens]

@HosamAlmoghraby FYI: we had a call with @pydanny and agreed to first get a release of the current state out of the door. So, except bug fixes and docs, I tend not merge anything else.

If this is done I would like to get the community of Cookiecutter together and let use plan the next steps in an open but well defined community process. Probably a Sprint (like the one in FOSS communities, not the scrum thing) would be a good idea. Just as a rough thought.

This will be better discussed over at the Cookiecutter Discord Server, so I stop here. I invite all people motivated to help to discuss over there.

[jensens]

So, it's done! @ericof and I released 2.1.0 https://pypi.org/project/cookiecutter/2.1.0/