by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:54
    cajhne commented #2229
  • 16:45
    ashtykazim labeled #2233
  • 16:45
    ashtykazim opened #2233
  • 16:21
    jaraco commented #2220
  • 15:59

    jaraco on master

    Add banner to main docs page Remove stale description of pac… (compare)

  • 15:51

    jaraco on readme-logo

    (compare)

  • 15:51

    jaraco on master

    Render logo in the readme. (compare)

  • 15:51

    jaraco on readme-logo

    Render logo in the readme. (compare)

  • 15:49

    jaraco on readme-logo

    Render logo in the readme. (compare)

  • 15:43

    jaraco on master

    Rename logo assets to remove pr… (compare)

  • 15:30
    jaraco commented #2229
  • 15:29
    jaraco closed #2227
  • 15:29

    jaraco on master

    Add logo resources Use lowercase 't' for consisten… Merge pull request #2229 from c… (compare)

  • 15:29
    jaraco closed #2229
  • 15:25
    jaraco synchronize #2229
  • 15:15
    jaraco commented #2232
  • 14:53
    jaraco commented #2232
  • 14:48
    jaraco commented #2232
  • 14:46
    jaraco commented #2232
  • 01:32
    cboylan commented #2232
Vicente Mataix Ferrándiz
@loumalouomega
Lets say that that main so we want to be an independent package of the others
Any idea?
I was thinking just to hardcode the changes on the setup.py
and add the dependencies as usual
Jason R. Coombs
@jaraco
Hi @loumalouomega . Setuptools (and much of the Python Packaging infrastructure) doesn’t do much for managing dependencies outside of the Python ecosystem. Tools like pip and setuptools rely on system package managers (and developers) to have satisfied external dependencies (compilers, Python versions, other libraries) before running the tool. In this section of the Python Packaging User’s Guide, there’s some guidance about how a user might rely on something like Conda or Spack or other tools to manage and install some of the more complicated dependencies. Other packages like lxml and Pillow mainly rely on custom build-time routines (or sometimes just instructions) to ensure that build dependencies are present before statically linking libraries.
Some work has been drafted/discussed on declaring “external dependencies”, but to my knowledge none has matured to a useable state.
For now, I would suggest avoiding using setuptools and setup.py to manage these dependencies and would instead build a custom workflow to orchestrate first the preparation of the external dependencies and second the building of the Python package (setup.py or pyproject.toml) that assumes the presence of the external dependencies.
Vicente Mataix Ferrándiz
@loumalouomega
Thank you very much
I was thinking in use poetry to deal with the dependencies
And adapt it to our case
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.