-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Move peps into subdirectory #10
Comments
This change moves all PEPs into the `peps/` subdirectory. The HTML files generated by `pep2html.py` will be located in `output/`. The `make` to convert a single PEP to HTML change slightly **if** you specify the path. It's still the when specifying the id. From: `make pep-0020.txt` To: `make peps/pep-0020.txt` ... just use tab completion ;)
This change moves all PEPs into the `peps/` subdirectory. The HTML files generated by `pep2html.py` will be located in `output/`. The `make` to convert a single PEP to HTML change slightly **if** you specify the path. It's still the when specifying the id. From: `make pep-0020.txt` To: `make peps/pep-0020.txt` ... just use tab completion ;)
This change moves all PEPs into the `peps/` subdirectory. The HTML files generated by `pep2html.py` will be located in `output/`. The `make` command to convert a single PEP to HTML has changed slightly **if** you specify the path. It's still same the when specifying the id. From: `make pep-0020.txt` To: `make peps/pep-0020.txt` ... just use tab completion ;)
So I think we shouldn't move files around because it'll mean that we can't view the complete file history on GitHub. |
Yep, unfortunately the move will break stuff, so I will close this. |
I wonder if changing the website field in the repo description to be |
Sigh. When will it be easy to do things that are obviously desirable? I sit
here in front of my top-of-the-line Map Pro thinking that in 100 years, if
the human race has survived, they will think of me much as I think of the
early humans who painted on cave walls and fashioned tools from flint. S
…On Tue, Nov 21, 2017 at 8:36 PM, Éric Araujo ***@***.***> wrote:
I wonder if changing the website field in the repo description to be
#python-enhancement-proposals or https://github.com/python/
peps#python-enhancement-proposals would help.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGbYEkXNpd0uBecV1zGb4ugbqFef6nzks5s4zQxgaJpZM4I3BVW>
.
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
|
Update images to show bin N
I'll reopen this since the reasons that was originally rejected due to are no longer applicable:
So, such a move will no longer break things as it would have in 2017, and this can be reconsidered. |
Is the README that important here? There's short description that could fit in GH's repo description, a link to Contributing Guidelines and a few things that probably should be moved to Contributing Guidelines. |
FWIW, this isn't just about the README at this point -- it'll also make it clearer what is "PEP sources" vs the supporting infrastructure around them. We have a non-trivial amount of supporting code and documents around PEPs living in the same repository currently, and moving PEP sources (+ supporting images etc) into a distinct folder will create a separation that would be useful. Whether the benefits are worth the transition costs is the main question IMO -- I think it is, which is why I've reopened this and suggested that this be reconsidered. :) |
PEP sources are |
+1
We could also reconsider #1 "Use .rst as the file extension for reST-based PEPs", which was also rejected due to history: #1 (comment). |
Indeed, that would also include #4. |
While it can't get us back the substantial hassle of having to finagle the includes/excludes to fix the many issues that dumping all the PEPs in the root directory and naming many of them Given that now the main reasons for not doing this (chiefly, GitHub not tracking moves) are no longer an issue (several other things surrounding this have been improved as well), I'm 👍 on this change (moving all the PEPs to a
To note, that was already completed many years ago and all the PEPs are using reST syntax internally, just that the old PEPs still used the |
I don't remember where, but someone made the point that for PEPs, the text files are the project, rather than in support of the project, as is the case with standard documentation. I'd be in favour of cleaning up the ancialliary files where possible, but I don't think we should move the files, even if we can. A |
Even so, many projects have their main project files under a subdirectory, for example |
That line of argument sounds a bit philosophical, but the point being discussed here is purely a practical matter due to the current code host in use. |
Indeed, that's pretty much all Python projects, many of which have the tests inline with the code in the subdir rather than under another subdirectory, along with many (most) other languages (e.g.
Indeed; practicality over purity. The reasons advanced for the move are essentially all practical in nature, namely:
Therefore, if we're going to move anything anyway (which git doesn't care if its a rename or a move), we may as well just do things properly at the same time to really get the benefit of it. |
@CAM-Gerlach, I would like to help transition all PEPs from .txt to .rst, moving them into a common subdir, etc, by creating a PR, just as @timofurrer attempted in 2016 via timofurrer@b6afc70.
|
The actual move (and rename of the PEPs to However, there are a number of tasks to fix outstanding technical/editorial defects that you could help with right now with relatively that should be much more achievable, helpful to use and beneficial to PEP readers and authors, such as:
To note, we don't generally suggest opening big PRs doing the same thing to a bunch of PEPs, especially as a newer contributor. Instead, a good approach to this is to pick one PEP that has at least one build warning, fix that and each of the other technical issues present (one type of fix per commit), and then submit that as a PR for review. See, e.g. #2751, #2754 or any of Hugo's other similar PRs for examples. I plan to open a meta-issue (hopefully later today; I've already written up a lot of it) documenting this approach and tracking the main remaining defect-fixing tasks that have value and meet the criteria, with a particular eye toward making it straightforward for any contributor to help with. Keep an eye out for that if you're interested in helping out. Thanks! |
Re: fixing warnings, here's the checklist I'd been working from. DetailsSorted by number of warnings
Fixed warnings
Remaining warnings
|
Wow, didn't know you were tracking that in such detail. That would be really good to include in the meta tracking issue I'm about to create covering that, I was just going to include a clean-up dump of the warnings I had) |
The numbers may be a little off by the shifting sands of fixing other warnings (e.g. a duplicate fixed in one fixes the other), but gives a good enough idea. |
@CAM-Gerlach The job can be started by looking for any links around and assume that anything with 404 response code is broken. For example https://bitbucket.org/larsyencken/simplestats/src/c42e048a6625/src/basic.py in https://peps.python.org/pep-0450/ If you have will and time, this would be extra helpful to hint us what is expected fix for this, where like above, the repository on bitbucket mentioned in PEP probably was removed. Web archive? Marking somehow links as not alive? Tried to find answers in https://peps.python.org/pep-0001/#pep-maintenance |
it's one of the lower-priority list items given the immense number of links (many thousands) among the various PEPs, and the average age of many of them (considering the PEPs span two decades). In general, I'd only recommend doing so on PEP if you're already in the process of updating it to fix the higher-priority items in the list (warnings, wrong syntax highlighting, missing headers, substantial rendering/technical defects), and focusing on the PEPs that have the highest-priority defects and those that are Draft, Accepted and Active (for Process/Informational) or Final (for Standards Track) first over those that are Deferred, Withdrawn, Rejected or Superseded.
You'd do this with
You'll want to use good case-by-case judgement, but in general, the fallback order I'd suggest is:
In this case, I just googled
This is much too technical and low-level for PEP 1, but I do have a draft of the meta-issue mentioned above that documents the outstanding defects considered significant enough to motivate fixes to existing PEPs, the overall strategy to address them to minimize noise, churn and notifications to authors while maximizing practical, holistic benefit, and the details of how to fix each one, but haven't quite finished it quite yet—I hope to do so very soon. |
This marks the closure of the final 'early' issue in the PEPs repo -- thanks to everyone for helping here! A |
The root directory listing is currently very long, which means that nobody will see github's readme rendering.
The peps sources could be moved into a subdirectory, separated from the scripts used to generate the rendered versions.
The text was updated successfully, but these errors were encountered: