Some limitations of pigar (actual use case)

[Felix Zedén Yverås]

I realized our current use case for pigar may be of interest, since it displays some limitations experienced "in the wild". I hope our experiences may assist in making pigar even better!

Use Case
We want to keep a large python project's dependencies up-to-date. The project's sources are split into multiple directories, separating services and shared code. Most packages we want to upgrade to their latest version directly, others we want to keep locked to specific versions for various reasons.

Issues

• Shared code is split into different directories. pigar currently only supports a single project PROJECT_PATH in the -P flag
  • Workaround: Run pigar once for each directory and manually merge the results.
• pigar currently does not support automatically upgrading all packages to their latest versions (See #80 )
  • Workaround: Use a separate tool to upgrade each package to their latest version or manually update via pigar -c
• pigar currently does not support locking certain packages to specific versions
  • Workaround: Manually overwrite pigar's output with our specific version after each run
• pigar may fail with e.g.
  django.core.exceptions.ImproperlyConfigured: Requested setting REST_FRAMEWORK, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.
  on django-enabled projects.
  • Workaround: Set DJANGO_SETTINGS_MODULE before calling pigar

We currently have most of this scripted but it would be nice to see such functionality built-in to pigar itself.

[Xiaochao Dong]

There is too much black magic available in Python's world.. and I have written some FAQs in the README: https://github.com/damnever/pigar#faq

Anyway, any ideas are welcome.