@ax3l I wish I had a better answer for you, but the short answer is that the Python Packaging ecosystem has always been focused primarily on (sourcing python modules and packages) and (installing those modules and packages for use).
ERROR: Package 'setuptools' requires a different Python: 2.7.10 not in '>=3.5'
If you mean
pip install . for building setuptools.
If you mean
pip install . for building other stuff, then no.
setuptools-scm newcomer question: When I tag a release with tag
0.0.1 infers the version as 0.0.2.dev0+gf47c788.d20200221. Doesn't dev0 indicate that it's a clean tree (no changes between workspace and tag)? I'd prefer to use version 0.0.1 in cases where there aren't any changes from the tag. How would I achieve that?
As seen on Azure CI for Ubuntu 18.04
I have a python package I'm trying to create a new setup.py for. The package source lives under src/engine/MyPackage I'd like sdist and all the packages to omit the src/engine. The docs indicate that using
packages = find_packages("src/engine"),
package_dir={"":"src/engine"}, should do that, but I'm still seeing src/engine in the paths when I tar tvfz my sdist package. What am I doing wrong?
Hmm. looks like it's doing what I want when I build a wheel though..
@bdbaddog Regarding removing
src/engine from the sdist doesn’t really make sense. An sdist is essentially a copy of the source, prepared for distribution. It’s still expected that the setup.py will be run against the expanded source distribution, meaning that if your sdist were to remove the src/engine, the setup.py that uses package_dir={“”: “src/engine”} would no longer be valid. Why not remove src/engine, find_packages, and package_dir and just have ./MyPackage in your source?
Anyone got a link to the legacy documentation for
setuptools? I've got an existing project that uses setup.py that I currently don't want to upgrade to whatever the latest flavour–of–the–month config format. But I'd like to understand what options I can pass to setup(...), yet I can't find the docs anywhere.
More DDG-ing found it: https://packaging.python.org/guides/distributing-packages-using-setuptools/#setup-args
Why isn't this documented on the setuptools project anywhere?
@zegelin Probably because Setuptools doesn’t own the syntax, but only extends what distutils does… and the args are described there (https://docs.python.org/3/distutils/setupscript.html).
There’s an effort underway for Setuptools to adopt distutils, including its documentation, so as that happens, the documentation should become more unified and clear.
Hi all, I'm curious as to whether there is any guarantee on the order in which requirements with environment markers are parsed in setup.cfg? I'm trying to think about how to simplify this kind of configuration: https://github.com/scipy/oldest-supported-numpy/blob/01cce7f8d725f3498e3730e9a890a61dc19110fb/setup.cfg#L25-L55
@astrofrog: I believe the requirements are considered unordered (or no guaranteed order), but more importantly, there’s no precedence, so while you could write
req==3 and req==4 (two different, conflicting versions), they’re both considered requirements of the package, and it’s probably up to the installer (pip or other) to determine the meaning of that declaration. So the way it’s written there is perhaps the best thing you have right now - a list of requirements all of which are mutually exclusive (only one active in a given environment).
@jaraco can you please address pypa/setuptools#2505, it's been blocking virtualenv for the last two weeks :-|
Hi there, and thanks for all the work you people are doing! I'm quite inexperienced in this area, but I'm contributing to a private Python project and wanted to set up proper packaging metadata for eventual PyPi release. I've mostly figured it out (I think), but this library will depend on a choice of parallelisation frameworks (ray OR charm4py) and I'm a bit stumped on how to specify required but mutually exclusive dependencies in the
setup.cfg. I know about extras_require but ideally I want a way to tell pip that one and only one of the frameworks needs to be installed. (Sorry if it's the wrong place to ask, I posted on r/learnpython but no one responded yet).
Hey @adigitoleo . What you’re asking for isn’t an existing feature. The closest you can get is to indicate each dependency as an extra (‘ray’ or ‘charm’) and then inform your users to indicate
yourlib[charm] or yourlib[ray]. If you’ll only ever have the two dependencies, you could nominate one as primary and indicate it as regular dependency and indicate the other as the extra, and if the extra is present, defer to it.
I agree it might be nice to have the feature you’re describing. I don’t know if it has been filed as a feature request, but if not, a good place to request it would be github.com/pypa/packaging-problems
(because although Setuptools might implement such a feature, it’s going to depend on some standards being developed in advance)
Thanks @jaraco ! I'll probably go with the 'extras' option for now. I'll might submit a request later this week as you suggest. Maybe something along the lines of what Arch Linux does with
provides in it's PKGBUILDs... well it's not critical and I'm glad I wasn't missing something obvious!
@jaraco any opinion on adding support in setuptools to consider
pyproject.toml with a ´[tool.setuptools.setup_cfg_data]` map and/or a multi-line string value of it (with the promise that the multi-line string will be certainly compatible and the map/nested map will approach compatible)
Howdy! I'm far from an expert on packaging and elf binaries, but I wanted to get people's thoughts on issues facing libraries using protobuf - e.g. grpc/grpc#24897, protocolbuffers/protobuf#8291 . The core of the issue appears to be Protobuf's Python library statically links in libprotobuf (https://github.com/protocolbuffers/protobuf/blob/master/python/setup.py#L188-L190) . In turn, when another library like tensorflow or gRPC also links in libprotobuf we get symbol conflicts and pain. To my knowledge this is pretty similar to the numeric stack's situation (e.g. numpy & scipy both use and ship libopenblas) which doesn't have these issues - but importantly instead of relying on static linking they ship .dylib or .so files patched up with auditwheel or delocate.
What would your suggestions be here as folks that are more expert in packaging? Is the numpy way the blessed way?
Thanks so much!
Sorry for the delay @RonnyPfannschmidt. Regarding
setuptools.setup_cfg_data, I’m not sure the context, but I think you’re asking about supporting pyproject.toml as another format to solicit config for setuptools. I’m not opposed to supporting pyproject.toml, but I’d really like not to have too many ways to do a thing… and setup.cfg is just now reaching maturity. I’d definitely like to avoid setup_cfg in the name. It should be meaningful keys like tools.setuptools.metadata or tools.setuptools.options (mapping to metadata and options in setup.cfg).
@jaraco between now and then i was made aware of https://raw.githubusercontent.com/python/peps/master/pep-0621.rst so the idea is zilch anyway
@jaraco as for the setup_cfg_data - it was merely to include setup.cfg data either verbatim or as nested structure without using up the complete tool.setuptools namespace to enable eventually working out meaningful keys
hmm, i need to put this on my element