CODEWITHSUNDEEP
pythonpython-packaging
Goffer
Goffer

Reputation: 97

Python packaging with demo

I've a question about python packaging. My project is a library and I would like to have a demo of how to use this library in the form of an application with GUI.

I'm thinking of doing the following by using the install_requires from setuptools:

Is that overkilled or is a decent way to approach it? Basically I don't want to bloat my library with an entire demo application.

edit:

I probably need to give a bit more context to explain the situation better.

Basically my Library is an API to represent data and interact with it. But since I’m only offering the representation part, it doesn’t actually do anything when you interact with it.

The idea behind the demo is to create an entire environment in the form of an application that will provide contextual data to represent -> represent it -> then connect it to the environment so that when the user interacts with the representation it actually does something such as modifying the data for example.

so in that demo, most of the content is context based and irrelevant to the Library and that’s what i’m referring to when I say clutter / bloat. it’s only there to provide a context to the user and have finished product that actually does something when they test it.

Also I realize that over time I could grow that demo even more to show more possibilities of implementation without having to change the library.

That’s why I want to separate it.

So basically I want to always install the latest compatible version of the demo when the library is installed and also potentially be able to separately update the demo to the latest version if needed.

I hope this make sense :)

Cheers,

Upvotes: 1

Views: 403

Answers (1)

Arne
Arne

Reputation: 20127

If a package provides some kind of optional feature that isn't part of the core functionality, it is usually gated with extras. This only addresses the dependencies your project has, the demo code would always be part of your library. That's usually ok though, because dependencies are where the really big chunks of bandwidth get wasted on.

Just to have an example to go on, the popular pyparsing package offers in its version 3 an extra called diagrams. The code to make diagrams work is part of the codebase and will be downloaded when installing pyparsing even without the extra. But its ~400 lines of code are nicely split off the core so that it can't possibly interfere with it. It's not clutter if it can safely be ignored.

The additional packages needed to make it work are a different story. On my machine, running pip install pyparsing==3.0.0a2 takes up 648kB of space. Running pip install pyparsing[diagrams]==3.0.0a2 adds 1872kB total, nearly three times as much. And this isn't even an extreme example, it just happened to be the last thing I installed which had an extra.

Summed up, if your optional feature doesn't introduce any additional dependencies, it's best practice to just include the feature. If it does introduce dependencies (e.g. some gui_lib_for_demo), split them off through extras, and maybe do something like this in your demo code

try:
    import gui_lib_for_demo
except ImportError:
    print("If you want to run the demo, please install this library with "
          "`pip install my_lib[demo]` instead.")

# actual demo code starts here

Upvotes: 1

Related Questions