TabViewer / gtabview

Simple graphical tabular data viewer
MIT License
33 stars 3 forks source link

Using entry_points for CLI #23

Closed s-celles closed 3 years ago

s-celles commented 8 years ago

Hi Yuri,

This might fix https://github.com/wavexx/gtabview/issues/20

See http://python-packaging.readthedocs.org/en/latest/command-line-scripts.html

Kind regards

wavexx commented 8 years ago

I was looking at this now, but moving the script within gtabview causes init to load prematurely. It's really a shame scripts=[] doesn't rewrite the header just like entry_points does.

goanpeca commented 7 years ago

@scls19fr @wavexx we need this fixed to make a conda package https://github.com/conda-forge/staged-recipes/pull/2934

Otherwise I will have to patch the recipe to do that

goanpeca commented 7 years ago

@wavexx why is moving this inside the package a problem? it seems like a natural thing to do

wavexx commented 7 years ago

I need to rework the initialization of Qt/Matplotlib in order to use entry_points. The current script delays the load of gtabview intentionally.

goanpeca commented 7 years ago

I need to rework the initialization of Qt/Matplotlib in order to use entry_points

Is this something you plan to work on? if not could you give me some pointers?

wavexx commented 7 years ago

On Sat, May 06 2017, Gonzalo Peña-Castellanos wrote:

Is this something you plan to work on? if not could you give me some pointers?

Yes, but I've been putting my attention on other projects lately, so I've been very slow.

In essence, entry_points requires a module to be loaded and installed. This would mean creating a dummy module for the bin script itself.

Since I didn't want to create a gtabview_script module (or something similar), but make it a submodule instead, there's a bunch of stuff to move out of the main init.

I have some uncommitted code to use gtabview as a general tabular converter (where all of this would make more sense - as Qt is never really needed), but I got stalled last year.

I'd rather fix it the proper way instead of just shoving it into a module to satisfy entry_points. Is this a big issue?

goanpeca commented 7 years ago

In essence, entry_points requires a module to be loaded and installed. This would mean creating a dummy module for the bin script itself.

Most python programs use a cli.py module (or more) as part of the package, and there is nothing dummy about it, so I don't understand. Sounds that you want to have two separate tools as part of the package and qt would be an optional dependency? Or you want to have two separate packages?

Since I didn't want to create a gtabview_script module (or something similar), but make it a submodule instead, there's a bunch of stuff to move out of the main init.

Still don't understand. Console entry points are used all the time to run GUI applications written in python. It does not have to be a command line tool only to make sense for it to be there.

http://setuptools.readthedocs.io/en/latest/setuptools.html

setup(
    # other arguments here...
    entry_points={
        'console_scripts': [
            'foo = my_package.some_module:main_func',
            'bar = other_module:some_func',
        ],
        'gui_scripts': [
            'baz = my_package_gui:start_func',
        ]
    }
)

I'd rather fix it the proper way instead of just shoving it into a module to satisfy entry_points. Is this a big issue?

I still fail to see why having an entry point to launch the GUI is an improper way of doing things??

wavexx commented 3 years ago

Closing via ba23fa1816ad0664d35b70e2dbfc163f9ecb84dd