Skip to content

Added documentation for using a pip requirements file. #3636

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 206 commits into from

Conversation

kchawla-pi
Copy link
Contributor

@kchawla-pi kchawla-pi commented Feb 18, 2018

Closes #3426
Created docs/guides/requirements-file with documentation on using a pip requirements file.

  • I have been unable to run pre-commit and am working to fix it. I will withdraw this pull request and submit a fresh one then.
  • The make html command is giving incorrect fonts, the standard Time New Roman, although it is displaying the correct fonts when I visit the website.
  • Next step is to attend to documentation for using the yaml file: http://docs.readthedocs.io/en/latest/yaml-config.html#requirements-file.
  • Help and feedback appreciated.

@@ -0,0 +1,104 @@
Read the Docs: Using a requirements file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the Read the Docs prefix isn't necessary, and we use title-case for h1 headers

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, once the requirements file has been created for either scenario;

- Login to your Read the Docs project ( you have to be admin of the project).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a trailing whitespace on the (

- From the list of your Read the Docs projects, click on the project you wish to modify.
- Click on the Admin button along the top row.
- Go to advanced settings.
- Enable the option ``Install your project inside a virtualenv using setup.py install``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The install project option is not mandatory for using the requirements file option

@stsewd
Copy link
Member

stsewd commented Feb 19, 2018

Thanks for your contribution, RTD have some guidelines when contributing to the documentation, take a look at https://docs.readthedocs.io/en/latest/docs.html.

Running pre-commit here isn't necessary, this is just for code.

@kchawla-pi kchawla-pi closed this Feb 19, 2018
 - Removed line `Enable the option Install your project inside a virtualenv using setup.py install.`
- Rewrote the section `Using the requirements file` to less verbose.
- Changed H1 heading to Title Case.
@stsewd
Copy link
Member

stsewd commented Feb 19, 2018

@kchawla-pi why did you close this PR? You can still working on this without closing it :)

@kchawla-pi
Copy link
Contributor Author

Huh. :-) Good to know. Thanks.
I made and pushed the changes from your review.
Currently working on the second yaml file case.

@kchawla-pi kchawla-pi reopened this Feb 19, 2018
humitos and others added 5 commits February 19, 2018 13:14
- Added label `.. _faq_document_package_not_at_root` for section
 `Can I document a python package that is not at the root of my repository?`
- Added reference to label `faq_document_package_not_at_root` in `faq.rst`.
- Changed heading for section on using requirements file via web admin interface.
- Removed the `/` at the root of example paths.
@kchawla-pi
Copy link
Contributor Author

Added section on how to use requirements file via a YAML file, and made some refinements to text from previous commits.
Somehow I copy-pasted text between editors and git marked the entire file's contents as new, or something. Not sure how , or how to fix that. Sorry about that.

Copy link
Contributor

@davidfischer davidfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a thorough guide!

Because of the multiple levels of headings, this guide really monopolizes the guides page. Let's add :maxdepth: 1 in guides/index.rst to keep that page cleaner.

screen shot 2018-02-20 at 3 56 10 pm

- You have multiple python packages in your project and you wish to document them.

-----------------------------
Using a pip requirements file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This duplicates the top heading. I think it can safely be removed.


You have enabled the install project in a virtual environment option, but your package's setup.py file is not in the root directory.
---------------------------------------------------------------------------------------------------------------------------------------
OR
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are headers with permalinks. A shorter heading would be better.

screen shot 2018-02-20 at 4 16 19 pm

Creating the requirements file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You are using external packages, extensions, and themes that you need to include in your documentation project
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This heading is very long and probably should probably be shorter. I realize the idea was to match the 3 cases outlined in the first section but perhaps something like "Supporting external packages, extensions, and themes" would work.

You are using external packages, extensions, and themes that you need to include in your documentation project
---------------------------------------------------------------------------------------------------------------

Read the Docs supports adding specific functionality, and themes to tailor the behavior and appearance
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comma here is unnecessary.

---------------------------------------------------------------------------------------------------------------

Read the Docs supports adding specific functionality, and themes to tailor the behavior and appearance
of your project's documentation. This is done by specifying a list of the packages, extensions, themes, to be used,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"packages, extensions, themes, to be used," -> "packages, extensions, and themes to be used"

To do this, one can create a list of requirements and save it in a requirements file.

Since *RTD* uses Python language to build the workflow which automatically converts and hosts your project's
documentation, and uses various python packages for this, the requirments file is the same as any standard python project.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"requirments" -> "requirements"


To do this, one can create a list of requirements and save it in a requirements file.

Since *RTD* uses Python language to build the workflow which automatically converts and hosts your project's
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"uses Python language" -> "uses the Python language"

 - Used different character for section underlines for better visual separation of sections.
 - Added :maxdepth: 1 to prevent cluttering index.rst with guides/using-requirements-file.rst subheadings.
 - Formatted headings to be more visually distinct among levels.
- Removed redundant heading `Using the pip requirements file`.
- Reduced verbosity of headings.
- Fixed grammar errors and typos.
 - Added clarification about the meaning of project and project root.
 - Added clarification about the meaning of project and project root.
- Sharpened the focus of the documentation to only using the feature.
- Replaced background and redundant information with appropriate links.
- Removed (outdated) warnings about beta status of `conda` support.
@kchawla-pi
Copy link
Contributor Author

Alright, I think I rebased correctly, didn't set my hair on fire, the build is passing. My make html is now glitching. Not sure why. My virtualenv was active.
Attaching the error logs i saved when trying to make from git bash and cmd.
sphinx-err-olqmm5.log
sphinx-err-abix_5.log

File "c:\python27\Lib\importlib\__init__.py", line 37, in import_module
    __import__(name)
ImportError: No module named dj_pagination

@kchawla-pi
Copy link
Contributor Author

Phew! Turns out, I could have 99 problems but a rebase ain't one.
I don't have 99 problems either, so pretty sweet.

@humitos
Copy link
Member

humitos commented Apr 2, 2018

ImportError: No module named dj_pagination

It seems that you created and installed some packages in your venv but then the requirements file changed and new packages needs to be installed.

You can:

  • re-create the venv (preffered)
  • re install dependencies: pip install -r requirements.txt

@kchawla-pi
Copy link
Contributor Author

BUMP!

@stsewd
Copy link
Member

stsewd commented Apr 15, 2018

@kchawla-pi it seems that something went wrong with the rebase, the diff shows that 180 files were modified.

@kchawla-pi
Copy link
Contributor Author

It included all the commits made since the original fork I believe. Isn't that what a rebase does, move the commit history to the head so it appears seamless? How do I address this? The checks indicate that it doesn't damage anything, and can be merged. What should I do?

@kchawla-pi
Copy link
Contributor Author

Should I open a new pull request in a new branch, with only the final changes made for the documentation?

@kchawla-pi
Copy link
Contributor Author

I hadn't pulled from the upstream master in a while. I did when I failed the Travis tests and pulled the upstream mater to my forked master. Is it not probable that 180 files would have changed in the intervening period? The tests are passing.
Any reviewers out there?

@RichardLitt
Copy link
Member

We'll review this when we have time, @kchawla-pi. I suspect that there was something wrong with the rebase; it's not normal to have commits from other authors in your branch after a rebase. However, the maintainers have limited time and effort, so there may be a gap before we're able to help and review this PR. Please be patient. Thanks.

@stsewd
Copy link
Member

stsewd commented May 10, 2018

Should I open a new pull request in a new branch, with only the final changes made for the documentation?

I think this is the best option here since I'm not sure if there is an easy way to solve the rebase error. If you do so, please link to this PR, so the review isn't lost :). Thanks for working on this!

@stsewd
Copy link
Member

stsewd commented Jun 6, 2018

@kchawla-pi are you still interested in opening a new PR with the changes?

agjohnson pushed a commit that referenced this pull request Jun 8, 2018
The original PR got confused about files changes. I cherry picked these from the
history. Hopefully this is most of the changes

Closes #3636
@agjohnson
Copy link
Contributor

👍 for a new PR, I've cherry picked the commits and fixed the rebase in #4212.

@ericholscher
Copy link
Member

Merging this in #4212 👍

ericholscher added a commit that referenced this pull request Jun 15, 2018
@kchawla-pi
Copy link
Contributor Author

I apologize for not attending to this, and more so for not informing the people here about my inability to do so.

@RichardLitt
Copy link
Member

@kchawla-pi Thanks for checking back in and having the courage to say that! It is appreciated. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Documentation on requirements.txt usage