Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:46
    jaraco commented #2788
  • 12:01
    jaraco commented #2788
  • 03:34
    ianb commented #2788
  • Sep 15 21:55
    DiddiLeija commented #2792
  • Sep 15 17:02
    jaraco commented #2788
  • Sep 15 16:59
    jaraco commented #2788
  • Sep 15 16:59
    jaraco commented #2788
  • Sep 15 15:58
    baryluk commented #2452
  • Sep 15 15:15
    jaraco labeled #2789
  • Sep 15 15:15
    jaraco unlabeled #2789
  • Sep 15 15:15
    jaraco closed #2789
  • Sep 15 15:15
    jaraco commented #2789
  • Sep 15 15:12
    jaraco commented #2789
  • Sep 15 13:34
    jaraco commented #1120
  • Sep 15 02:39
    mcarans commented #1347
  • Sep 15 02:29
    chandchowdary commented #1120
  • Sep 15 02:28
    chandchowdary commented #1120
  • Sep 15 02:13
    mcarans commented #1347
  • Sep 15 01:59
    mcarans commented #1347
  • Sep 15 00:01
    jaraco labeled #2790
Vicente Mataix Ferrándiz
@loumalouomega
But maybe I would do as youy suggest
Thank you very much
Axel Huebl
@ax3l
Hi! I am generating in a CMake workflow some libraries via pybind11 and install them already successfully. Now I am also generating a binary executable that I want to distribute with my wheel into a PATH location. Just adding the generated binary to setup(..., scripts=['mytool']) does not work (not found) and just generating it in extdir installs it alongside the python prefix ('-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=' + extdir), but does not add it to the PATH. What do you recommend to specify in setuptools:setup to install an executable that is generated from an external build?
This is what I am doing so far for libraries: https://github.com/openPMD/openPMD-api/blob/dev/setup.py
And a new executable named "openpmd-ls" comes in here: openPMD/openPMD-api#574
Axel Huebl
@ax3l
@jaraco do you know how I can express the installation of an externally built executable in setuptools:setup?
Paul Ganssle
@pganssle
@ax3l You can't, really.
It's one of the higher-priority open questions to solve for the Python packaging ecosystem.
Axel Huebl
@ax3l
:'(
Ronny Pfannschmidt
@RonnyPfannschmidt
@pganssle do i recall it correctly that you are trying to solve editable installs for the peps - i was wondering, what if the solution was to generate a special wheel, tagged with +for_editable_install that would contain metadata, a record and the files that the build backend would need to make things work
afterwards that wheel would be installed just like any other wheel, just that instead of shipping the package content, it ships a shim belonging to the controll of the backend
Axel Huebl
@ax3l
@pganssle sorry for the delayed ping, is there a github issue I can subscribe to regarding the install problem I mentioned?
you mentioned its one of the higher-priority ones
Axel Huebl
@ax3l
Hi, we are currently encountering an installation problem with easy_install.py ignoring a user-provided --prefix and trying to install in a system-location instead. Any ideas if that is a setuptools installation bug and how to work around it? pypa/setuptools#1930
Jason R. Coombs
@jaraco
@RonnyPfannschmidt If I recall correctly, the design is to have the build backends provide a list of sources which a frontend (like pip or tox) could symlink or (repeatedly) copy to make present in sys.path. It far from a solved issue, though.
@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).
Axel Huebl
@ax3l
I see, but prefix-isolation seams to be something it knows in general... no?
Ian
@ionox0
Has python 2.7 reached it's end with the pip install . command?
ERROR: Package 'setuptools' requires a different Python: 2.7.10 not in '>=3.5'
Ian
@ionox0
^just had to use a previous version of setuptools to get it to work for now
Paul Ganssle
@pganssle
@ionox0 Yes.
If you mean pip install . for building setuptools.
If you mean pip install . for building other stuff, then no.
corentin
@corenti13711539_twitter
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?
corentin
@corenti13711539_twitter
My Jenkins build seems to make some unexpected changes to the checked out repo, so apparently the repo is dirty at build time. Which would explain the version number inferred by setuptools-scm.
Axel Huebl
@ax3l

This confuses me a lot:

$ python3 -m pip install -U pip setuptools wheel cmake --user
Collecting pip ... 
Collecting setuptools ...
Collecting wheel ...
Collecting cmake ...
      File "<string>", line 1, in <module>
    ModuleNotFoundError: No module named 'setuptools'

Just... why? #help

As seen on Azure CI for Ubuntu 18.04
Ronny Pfannschmidt
@RonnyPfannschmidt
@ax3l when the setup of cmake runs setuptools is not yet installed, use a extra command to install cmake
Axel Huebl
@ax3l
yes, I now install in two steps. but... why can't pip figure this out?
Axel Huebl
@ax3l
uff, should have been posted in pypa/pip. moved now.
William Deegan
@bdbaddog
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..
William Deegan
@bdbaddog
Still is there a way to remove src/engine from the sdist package?
William Deegan
@bdbaddog
Is this channel pretty much dead? Is there a better place to ask questions?
Jason R. Coombs
@jaraco
This channel isn’t dead; it’s just that I don’t get to it as often as I’d like. I still welcome questions here, but Github issues is also a good place.
@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?
William Deegan
@bdbaddog
@jaraco - many outstanding PR's in flight.. and I guess we'd lose easy access to git history though could use -follow I beleive but the default wouldn't.
Jason R. Coombs
@jaraco
@bdbaddog In my experience, git is competent at tracking moves, especially if moves are invoked via git. But I grant you, that’s troublesome. If that’s your only constraint, I’d recommend pushing through it and doing away with the complications it adds.
Ronny Pfannschmidt
@RonnyPfannschmidt
@jaraco git does not track any moves at all - it always infers them from the snapshots (hence some people moving files in separate commits before commiting changes to get better merge handling)
William Deegan
@bdbaddog
Good morning. Finally got around to reorging my source tree to get rid of src/engine/SCons and just make it SCons but getting stuck on changes needed for setup.cfg... It's no longer including some important package data..
William Deegan
@bdbaddog
Got it.. Forgot to modify MANIFEST.in.. ideally if there was a directory referenced in MANIFEST.in which didn't exist, there's be some warning/error?
Jason R. Coombs
@jaraco
@bdbaddog There may be room for improvement there. I’m not familiar with the history, so don’t know what confounding factors may be lurking.
Adam Zegelin
@zegelin
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.
Adam Zegelin
@zegelin

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?

Jason R. Coombs
@jaraco
@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.
Simsalaba
@Simsalaba
I'm using setuptools to create a dist but my python script requires a C executable. Can I make it so that the Setup.py gets the repo, builds and installs the C-code when it's installing my script?
Ronny Pfannschmidt
@RonnyPfannschmidt
@Simsalaba typically thats not safely possible in a portable way - with some mored etails a workable suggestion may be possible (like for example distro or flatpack based distribution) - whats the use-case of the dist?
Thomas Robitaille
@astrofrog
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
Jason R. Coombs
@jaraco
@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).