search

Holzhaus / sphinx-multiversion

Sphinx extension for building self-hosted versioned docs.
https://holzhaus.github.io/sphinx-multiversion/
BSD 2-Clause "Simplified" License
148 stars 65 forks source link

Integration with setuptools #79

Open wvxvw opened 2 years ago

wvxvw commented 2 years ago

Calling separate commands to build documentation isn't really an option for the project I'm working on. Too much blood, sweat and gore went into creating setup.py. Until now, I used setup.py build_sphinx command to generate documentation. When I look at your project's main.py I see that it will be hard to make it work out of the box (all that stuff about sys.flags..., you don't separate parsing arguments and the logic of the rest of your code, it's all in one place, impossible to separate).

Are there any plans for integration with setuptools? And, before you get defensive etc. If there aren't any plans, then there aren't. If you prefer the argument parsing to be intermixed with configuring Sphinx and doing other stuff--that's your project. I'm not telling you how to live your life. I'm just explaining why it's not usable in my context.

CAM-Gerlach commented 2 years ago

Hey @wvxvw , just FYI, unfortunately setup.py commands (and direct invocation of setup.py in general) has been deprecated for many years now, is a very bad idea in general and will stop working at some point in the immediate future. The intended replacement is with a more appropriate tool, such as Tox or (for your use case, given you're defining your own custom scripted commands) Nox. Aside from anything too tightly entangled with the setuptools/distutils logic, porting your current code to Nox should be mostly copy/paste plus adding a hook to call it.

Also, just FYI, as you might have noticed from the last commit date, lack of response here and the open issues and PRs, this project has unfortunately not really been actively maintained much lately, and results in build failures for me on Sphinx 4.x, as far as I can tell. As such, maintainer bandwidth, if there is any, is likely going to be prioritized toward getting things fully working again as opposed to integrating with a long-deprecated, highly bespoke and uncommon use case, and so this might not be the best tool for you.

Finally, just FYI, I'm not a maintainer or anything, but given this is a community-developed, volunteer-maintained open source project, the blunt criticism of the project's current approach, aggressive remarks like "before you get defensive", and aggressive tone are not typically the most conducive to receiving a positive reply.