Add dynamic dependency in pyproject.toml - #111

@bobleesj we might still want to check how to do with build requirements.

Also this apply to all the package people are working on as well as the finished ones (diffpy.utils, diffpy.pdfmorph, and diffpy.labpdfproc)

Also this apply to all the package people are working on as well as the finished ones (diffpy.utils, diffpy.pdfmorph, and diffpy.labpdfproc)

As requested by @sbillinge I made an issue to all of the relevant ones.

@bobleesj we might still want to check how to do with build requirements.

Could you elaborate on this for me? @Tieqiong

Also this apply to all the package people are working on as well as the finished ones (diffpy.utils, diffpy.pdfmorph, and diffpy.labpdfproc)

As requested by @sbillinge I made an issue to all of the relevant ones.

Thanks

@bobleesj we might still want to check how to do with build requirements.

Could you elaborate on this for me? @Tieqiong

So in requirements there are several files containing different categories of dependencies. The most obvious one we want to include in pip install is the run.txt which include all the dependencies for running the package. There's also the build.txt. It's not very important for most of the packages (as it only contains python and setuptools) but it might be a bit tricky for c packages (such as diffpy.pdffit2) because it contain gsl (see diffpy/diffpy.pdfgui#184) which is the dependency to build locally. See this from Simon from diffpy/diffpy.structure#98:

Very slow internet here so not sure if I can test befoer I have to board plane. But in answer to the other questions, I agree that adding a requirements/build.txt in cookiecutter would be good as this will differ between c and non-c packages. Is there a way to add the c requirements but somehow commentd out? It iseasier to delete things that have to add them and not know the correct name/syntax

@Tieqiong we want to figure out how to handle the build requirements in general, but I think this does not apply to this PR, right? What this PR does is that it installs all dependencies that a package needs to run when a user types pip install <package>. This has nothing to do with building the package, so that work can be done on separate PRs I think.

Please confirm and I will merge this.

Thanks @Tieqiong for the explanation.

@Tieqiong we want to figure out how to handle the build requirements in general, but I think this does not apply to this PR, right? What this PR does is that it installs all dependencies that a package needs to run when a user types pip install <package>. This has nothing to do with building the package, so that work can be done on separate PRs I think.

Please confirm and I will merge this.

Yes I agree build is another issue and this PR is enough if we are not considering c packages. However the changes that would be made for including build requirement is almost the same (adding build.txt in the dynamic list) and that matters for pip installing the cpython packages. So I think it's actually good to include it here too.

@bobleesj please make an issue, if it isn't there already, about the build packages. We will do that with on s separate PR