Missing LICENSE file

[maresb]

Hi, I'm interested in redistributing this package on conda-forge. While the README declares the MIT license, there is no corresponding LICENSE file. The conda-forge policy requires that a LICENSE file be present.

[maresb]

There are GitHub instructions for setting up a template here

[CNSeniorious000]

Thanks! Added in 5093684. Feel free to let me know if you have any other questions!

[maresb]

Perfect, thanks so much!!!

Would you be able to cut a release to PyPI including this LICENSE file? (We source our builds from PyPI sdists.)

[CNSeniorious000]

Oh, I'll get it released tomorrow. Looks like this is one of the earlier projects I worked on, and back then, I didn't set up a workflow for PyPI publishing. I'll need to hop on my computer and sort it out after I wake up. It's already 1:56 AM here in the GMT+8 time zone, haha.

[maresb]

Amazing, thanks so much! Sleep well!

For when you wake up, I'd recommend checking out trusted publishing workflows if you haven't already. In GitHub, under "Security" -> "Environments" you create a new environment called release. Then add yourself as a required reviewer. On the PyPI side, go to publishing settings and add a new trusted publisher from GitHub, org promplate, repo partial-json-parser, environment release, and workflow file release.yaml (or whatever you call the file under .github/workflows/. Then in the workflow you build the package (I like https://github.com/hynek/build-and-inspect-python-package), and then use pypa/gh-action-pypi-publish@release/v1 in a separate upload-to-pypi job and without a token, if you instead add permissions: id-token: write and environment: release to the upload-to-pypi. (I typed this from memory, so expect minor variations, but in the end it's super easy!)

[CNSeniorious000]

0.2.1.1.post5 done. Sorry for lagging. Thank you for providing these information! I directly use uv publish at last because it is the fastest way.

[maresb]

Thanks so much for the release!!! Please don't apologize, one day turnaround is very fast!

I took a look at your workflow and it makes me concerned: can I trigger a release by myself without your consent by pushing a PR after changing the version??? (If you are confused, then I could make an attempt with a low version number to demonstrate my theory.)

At the very least I think you should set up a GitHub environment so that your approval is required before a release occurs. (See my last comment.)

[CNSeniorious000]

Wow I see. That's dangerous indeed! I will take a look at how GitHub environments work.

[maresb]

@CNSeniorious000, I see you set up a GitHub environment, and I assume that you added yourself as a required reviewer? Having yourself as a required reviewer is necessary in order to prevent the exploit.

I directly use uv publish at last because it is the fastest way.

Note that build-and-inspect-python-package uses uv build but also includes lots of optimizations and additional checks.

Thanks so much for the quick release with the LICENSE file. I have submitted partial-json-parser to conda-forge, and it will be available there shortly.

[CNSeniorious000]

Good. Thank you for providing so much information these days! Yeah I see build-and-inspect-python-package also does some linting stuff. I may try it in other projects or next release of this one.

Thank you so much for your submission to conda-forge! As I'm not very familiar with conda-forge yet.

[maresb]

My pleasure!

Conda-forge is a packaging ecosystem that's not limited to Python. It's popular for scientific applications, like where you might want to manage C or Rust compilers, CUDA, and even Python itself as project dependencies. If you are working in pure Python, then there is little point, and I'd recommend sticking with uv.

However, in case you are interested, then you might want to check out https://pixi.sh which is a tool that extends uv to work with conda-forge.

[CNSeniorious000]

Cool! I'm collaborating on a biological project that uses several conda dependencies. I previously struggled to make uv and conda work together, leading to complicated commands like 🤯

RUN uv v && conda create -p .venv -y && conda install -p .venv -c conda-forge -c bioconda mmseqs2 -y && conda install -p .venv conda-forge::mafft -y

Looks like pixi is a modern solution for me.

[maresb]

Ah, amazing!!!

The trick to succeed with pixi is to install everything first as conda packages whenever possible. Only as a last result should you use pypi dependencies. Furthermore, if you need a pypi dependency because something is not on conda-forge, you should add as many subdependencies as possible. The goal is to minimize the number of pypi dependencies in the lockfile.

Another trick is to not use pixi's pyproject.toml functionality, and instead always use pixi.toml. The reason is to understand your project as a Python project defined by pyproject.toml, and separately and more broadly as a pixi project defined by pixi.toml. So pyproject.toml defines what will be uploaded to PyPI if you publish your project, while pixi.toml (referencing your Python project with a pypi dependency of the form myproject = { path = ".", editable = true }) defines the Conda environment for your project, and has nothing to do with PyPI.

Also, you can add stuff to conda-forge yourself by using a tool called Grayskull and making a PR to staged-recipes like conda-forge/staged-recipes#28793. Now that that's been merged, the Conda build is managed in https://github.com/conda-forge/partial-json-parser-feedstock, and a PR will automatically open whenever you publish a new version to PyPI.

Good luck with everything!