Selectively fixing entry points

[hmaarrfk]

I notice that the entry points are always fixed whenever somebody installs any desktop app.

I have a few scripts defined in the top level module that I would prefer not being modified whenever somebody installs a subpackage that runs desktop-app install.

Would you accept PRs to add flexibility in how, and when fix_entry_points is called on windows?

I would start with providing a:

• "disable" switch when installing a desktop app.
• a subcommand to fix a specific entry-point

that should cover my bases.

I'm sure other organizations are possible, so feel free to suggest.

Thanks for all your hard work on this!

[chrisjbillington]

I am open to changes like that, but I'm wondering what the motivation is to avoid re-making them.

The remaking is using the same mechanism as used by pip itself when building wheels, so should be quite kosher. Is the desire to avoid remaking them "just in case" something goes wrong with desktop-app that introduces a bug? Or is it to save time, or to preserve file hashes, or something like that?

[hmaarrfk]

I'm using a few conda packages as virtual packages that enable or disable different GUI entry points. I would like to avoid polluting the PATH with too many unnecessary applications of mine.

For now, my "solution" has been to simply remake the entry points, but I do see this is a cleaner way to avoid clobbering files that the sub application doesn't own.

Now that I think about it, each application should keep track of the files it creates. Ideally, conda and pip can do that. However, they don't do such a good job integrating with the user's desktop file and lnk directory. By being able to generate them selectively, each GUI virtual package can maintain its own exe and script files in the post-link and pre-unlink steps.