Manually upgrade 0.1.3 -> to 0.1.4

[sahiljhawar]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mcoughlin]

@sahiljhawar So after you merge this, then you will revert the yaml to the syntax they had before for future pypi uploads?

[sahiljhawar]

Yes, I think so. By the next release if our PyPi size limit is not increased we can still use the same config. Only caveat is, we have to do it manually.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• requirements: run: matplotlib-base<3.8,>=2.0 must contain a space between the name and the pin, i.e. matplotlib-base <3.8,>=2.0

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[sahiljhawar]

I am not sure what is going wrong. But here are my assumptions/observations:

• When rendering using conda-smithy, it checks for the conda-smithy version and then only renders the package. Since conda-smity 3.31.0 is in broken state right now it cannot be installed from conda. I tried installing from source but that also didn't work. Therefore I installed conda-smithy in 'broken' state (conda install conda-forge/label/main::conda-smithy) and used it to render and it worked fine (didn't raise any error).

• We can see obvious changes in the new scripts, but I believe there is more to the broken smithy. I reverted the build scripts to previous version but the CI again failed, maybe the changes in the scripts are needed by smithy 3.31.0.

I will do: @conda-forge-admin, please rerender. However, in the mean time if you get a solution please push it.

[sahiljhawar]

@conda-forge-admin, please rerender

[sahiljhawar]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/nmma-feedstock/actions/runs/8026264990.

[sahiljhawar]

@conda-forge/core Hi again, I have tried multiple times (on local as well) but the pipeline never passes. I am assuming the root cause is ClobberWarning and I have tried to change the Python versions but the error still remains. Can you please help in fixing this? Am I missing something?

[hmaarrfk]

I think you should have a section in your pyproject.toml

called

tool.setuptools

see maybe

https://github.com/hhatto/autopep8/blob/af7399d90926f2fe99a71f15197a08fa197f73a1/pyproject.toml#L44

[sahiljhawar]

@hmaarrfk We already have that: https://github.com/nuclear-multimessenger-astronomy/nmma/blob/25fe95e955efca90b8decdca89e5afb2406cafa7/pyproject.toml#L75

[hmaarrfk]

Try;

[tool.setuptools.packages.find]
include = ["nmma*"]

it seems like it isn't searching through subdirectories. I haven't been too fond of the pyproject.toml transition and avoided it in my projects, but the pip command isn't finding the subdirectories with the syntax you chose.

[sahiljhawar]

But we already had 3-4 conda releases with pyproject.toml and went fine

[mcoughlin]

@sahiljhawar Is this a case where a 0.1.5 release would alleviate these issues?

[hmaarrfk]

But we already had 3-4 conda releases with pyproject.toml and went fine

If you have a linux machine, try to do:

python build-locally.py --debug 

then activate the environment, and edit things until you see that the whole subdirectories are installed correctly. That is what I did and found that the proposed changes to the pyproject.toml worked.

As I said, I had a really rough time with the pyproject.toml transition and this is par for the course.

[sahiljhawar]

@mcoughlin Can't say for sure. I can try implementing Mark's suggestion and if it works maybe a 0.1.5 or uploading that local build on anaconda (if it's possible).

[sahiljhawar]

@hmaarrfk I am using Github codespaces to test this out as it allows for a clean base environment (0 chances of any conflicts).

[hmaarrfk]

For your reference build locally uses docker to also create the same build environment. Good luck

[sahiljhawar]

Thanks @hmaarrfk. Your code snippet worked. Looks like since we changed some configuration in the pyproject.toml it was not working well with the conda build process

[sahiljhawar]

@conda-forge-admin, please rerender