Should pkg_resources be vendored? #1169

Activity

1. diraol commented on Jun 27, 2023

   

   diraol

   on Jun 27, 2023

   Contributor

   More actions

   Hi @mkohler ! Thanks for reporting it.

   That would be something we can do, indeed (this dependency on setuptools/pkg_resources was a real pain some time ago in this project).

   But I was looking at the package website and saw this warning:

   Use of pkg_resources is deprecated in favor of importlib.resources, importlib.metadata and their backports (importlib_resources, importlib_metadata). Some useful APIs are also provided by packaging (e.g. requirements and version parsing). Users should refrain from new usage of pkg_resources and should work to port to importlib-based solutions.

   So, I was wonder. Would it make more sense to add pkg_resources as a vendored lib in this project or try to replace it in the upstream projects? (honest question!)

   I think the effort to replace them in the upstream packages may be smaller than vendoring it over here, but this is just a guess from my side.
2. Drachenfels commented on Jul 12, 2023

   

   Drachenfels

   on Jul 12, 2023

   More actions

   My 2 cents, pkg_resources is causing a bunch of issues on an older version of Ubuntu, whenever I run pdm sync or poetry install it removes pkg_ressource==0.0.0 that comes with virtualenv and installs the newest version from pypi. A side effect is that python-mode breaks. Pain!
3. mkohler commented on Aug 12, 2023

   

   mkohler

   on Aug 12, 2023

   Author

   More actions

   Would it make more sense to add pkg_resources as a vendored lib in this project or try to replace it in the upstream projects? (honest question!)

   I think it would be better to replace it in upstream projects, because of the information you cited, and the fact that importlib.resources has been in the standard library since Python 3.7, which presumably means no one has to vendor it.
4. moorepants commented on May 25, 2024

   

   moorepants

   on May 25, 2024

   More actions

   I manually vendored setuptools/pkg_resources in my local install and it solved issues with pylama importing. pylama has a single import form pkg_resources and there hasn't been development activity there in some time.
5. rmax commented on Oct 26, 2024

   

   rmax

   on Oct 26, 2024

   More actions

   There is a pylama PR for this klen/pylama#254

   👍React with 👍1Reacted by Kliment
6. pykler commented on Jul 12, 2025

   

   pykler

   on Jul 12, 2025

   Last edited by pykler

   More actions

   @mkohler I guess this is still not fixed, this is what I ended up doing to get it working in nixos home-manager

   let
     python_mode = (
       pkgs.vimPlugins.python-mode.overrideAttrs (oldAttrs: {
         buildInputs = oldAttrs.buildInputs or [ ] ++ [ pkgs.python3.pkgs.setuptools ];
         postInstall =
           oldAttrs.postInstall or ""
           + ''
             echo "Patched with vendored setuptools" >>$out/readme.md
             for p in pkg_resources setuptools; do
               ln -s ${pkgs.python3.pkgs.setuptools}/lib/python3*/site-packages/$p $out/pymode/libs/$p
             done
           '';
       })
     );
   in
   {
     programs.vim = {
       enable = true;
       plugins = with pkgs.vimPlugins; [...] ++ [python_mode];
       ...
     };
   }
   
7. diraol commented on Jul 12, 2025

   

   diraol

   on Jul 12, 2025

   Contributor

   More actions

   Hey folks, sorry for the long time without news here.
   A small kid around the house has consumed all my time to side projects (and I haven't been using the plugin on a daily basis also).

   Anyway...
   I've just sent a quite big refactor on the project test flow, using docker, and I've also added test steps for newer python versions. (actually, I'm dropping support for python prior to 3.10 since it up to 3.9 is already quite old).

   I still need to warm up my mind with the plugin code, but I would love to have it improved - and any help will be very much welcome by the way!

   Things like eventually replacing some of the submodules with ruff and deprecating old stuff (such as these dependencies) as much as possible.

   Again all help will be very much welcome.
8. diraol commented on Jul 12, 2025

   

   diraol

   on Jul 12, 2025

   Contributor

   More actions

   I've opened a new issue for us to discuss a bit, as community, what's the best approach.
   #1190

   Please, send your contributions there.