Na und? Einmal ist es der Projektname (bzw Name des Repos) und einmal ist es der Paketname.Sophus hat geschrieben:Man könnte src auch einfach den Namen meines Projektes geben, aber mein Top-Level-Ordner, also der aller erste Ordner trägt ja schon den Namen meines Projektes.
Gute Verzeichnisstruktur?
@snafu: So nach dem Motto "Doppelt hält besser"? Verzeih für mein Anfängerverhalten. Denken wir kurz von GitHub und sonstige Plattformen weg (weil du Repo angesprochen hast). Wenn ich auf mein D:\ Laufwerk gehe, sehe ich einen Ordner xarphus, also weiß ich, es handelt sich um mein Projekt. Öffne ich den Ordner, dann sehe ich nochmal den Ordner xarphus neben anderen Dateien wie LICENCE, README, DISTRIBTION etc.? Kommt mir irgendwie seltsam vor. Liegt aber auch daran, dass ich dieses "Denken" noch nicht gewohnt bin?
@Sophus:
Beim Stichwort Repo gehts hier nicht um irgendeine Quelltextplattform im Internet, sondern um Dein Repo (Das Projekt ist hoffentlich mit einem VCS Deiner Wahl versehen.) Ansonsten wurden Dir doch schon genug Bsp. genannt, von denen Du Dir Deine Struktur ableiten kannst.
Üblich für Python ist z.B. alles Projektbezogene (Lizenz, LIESMICH, Doku, Pythonpaketordner etc.) auf oberster Repoebene zusammenzuführen (Projektordner - der Name ist hier Schall und Rauch und eigentlich nur für Dich wichtig zum Wiederfinden/Identifizieren des Projektes). Die Pythonpaketordner heissen dann so, wie sie im Pythonimport auftauchen sollen (bei Dir wahrscheinlich 'xarphus', 'xarphus.core' etc.). Im besten Falle deutet der Name der Pakete/Module die Funktionalität an. Auch sollte da alles rein, was fürs korrekte Ausführen des Pythoncodes von Belang ist. Alles andere fliegt da raus. Warum? Weil Du so Distributoren das Leben leichter machst und später z.B. im Pythonpfad nur laufzeitrelevante Dateien landen. So lagern Distributoren z.B. die Doku lieber unter /usr/share/doc aus.
Beim Stichwort Repo gehts hier nicht um irgendeine Quelltextplattform im Internet, sondern um Dein Repo (Das Projekt ist hoffentlich mit einem VCS Deiner Wahl versehen.) Ansonsten wurden Dir doch schon genug Bsp. genannt, von denen Du Dir Deine Struktur ableiten kannst.
Üblich für Python ist z.B. alles Projektbezogene (Lizenz, LIESMICH, Doku, Pythonpaketordner etc.) auf oberster Repoebene zusammenzuführen (Projektordner - der Name ist hier Schall und Rauch und eigentlich nur für Dich wichtig zum Wiederfinden/Identifizieren des Projektes). Die Pythonpaketordner heissen dann so, wie sie im Pythonimport auftauchen sollen (bei Dir wahrscheinlich 'xarphus', 'xarphus.core' etc.). Im besten Falle deutet der Name der Pakete/Module die Funktionalität an. Auch sollte da alles rein, was fürs korrekte Ausführen des Pythoncodes von Belang ist. Alles andere fliegt da raus. Warum? Weil Du so Distributoren das Leben leichter machst und später z.B. im Pythonpfad nur laufzeitrelevante Dateien landen. So lagern Distributoren z.B. die Doku lieber unter /usr/share/doc aus.
http://lmgtfy.com/?q=VCS+programmingSophus hat geschrieben:@jerch: Was ist ein VCS?
@snafu: Ich verstehe, also "VCS Verkehrs-Club der Schweiz"?
Nein, habs schon verstanden, dass es Version Control System bzw. Versionsverwaltung meint. Sowas wie Github oder Bitbucket.
EDIT:
Jetzt schummelst du, snafu Du hast den google-Link schön verändert, weil dir der Verkehrs-Club der Schweiz nicht gefällt
Nein, habs schon verstanden, dass es Version Control System bzw. Versionsverwaltung meint. Sowas wie Github oder Bitbucket.
EDIT:
Jetzt schummelst du, snafu Du hast den google-Link schön verändert, weil dir der Verkehrs-Club der Schweiz nicht gefällt
Naja nicht ganz. Diese Plattformen zeigen Dir nur einen Teil dessen, was heutige VCS leisten können und haben zusätzliche Funtionalität, welche nicht aus dem zugrundeliegenden VCS kommen. Daher VCS != Github bzw. Bitbucket. Bekannte VCS sind z.B. git, mercurial, Subversion und CVS.Sophus hat geschrieben:Nein, habs schon verstanden, dass es Version Control System bzw. Versionsverwaltung meint. Sowas wie Github oder Bitbucket.
@Sophus: Was jerch möglicherweise sagen will: Ein VCS muss nicht zwangsläufig ins Internet gestellt werden. Ein VCS dient einfach dazu, den Fortlauf eines Projekts in einer Art Historie darzustellen, sofern man es denn entsprechend verwendet. Es zeichnet sich dadurch aus, dass alte Stände angesehen und ggf auch zurückgeholt werden können. Du kannst mithilfe von Kommentaren in einer Übersicht immer schön sehen, wann was gemacht wurde.
Ein heutiges VCS unterstützt auch mehrere Zweige. Daher kann z.B. Python 2.7 neben dem aktuellen Python 3.x entwickelt werden. Manche Neuerungen werden in beide Zweige eingespielt, andere nur in den aktuellen Zweig. Auch kleine Hobby-Projekte können davon profitieren, wenn man z.B. Zweige für experimentelle Zwecke verwenden will. Wenn das Experiment gegen die Wand gefahren wurde, dann wirft man es weg und entwickelt am Hauptzweig weiter. Wenn es erfolgreich war, führt man es mittels eines bestimmten Kommandos mit dem Hauptzweig zusammen.
Möglicherweise ist das ja auch für dich mal einen Blick wert...
Ein heutiges VCS unterstützt auch mehrere Zweige. Daher kann z.B. Python 2.7 neben dem aktuellen Python 3.x entwickelt werden. Manche Neuerungen werden in beide Zweige eingespielt, andere nur in den aktuellen Zweig. Auch kleine Hobby-Projekte können davon profitieren, wenn man z.B. Zweige für experimentelle Zwecke verwenden will. Wenn das Experiment gegen die Wand gefahren wurde, dann wirft man es weg und entwickelt am Hauptzweig weiter. Wenn es erfolgreich war, führt man es mittels eines bestimmten Kommandos mit dem Hauptzweig zusammen.
Möglicherweise ist das ja auch für dich mal einen Blick wert...
@snafu und jerch: Klingt alles sehr schön und interessant. Ich habe mir schon vor längerer Zeit, als ich mich zum ersten Mal für Python interessierte ein Konto bei GitHub und Bitbucket eingerichtet. Aber wie kann man außerhalb dieser Plattform und außerhalb des Internets eine VCS betreiben? Einfach per TXT-Datei jeden Tag so eine Art Entwicklertagebuch schreiben?
In Etwa so?
01.05.2015
- Funtion XY wurde verbesser
- Function XY wurde hinzugefügt
02.05.2015
- Funktion XY wurde aufgelöst und in Klasse umgewandelt
- ...
In Etwa so?
01.05.2015
- Funtion XY wurde verbesser
- Function XY wurde hinzugefügt
02.05.2015
- Funktion XY wurde aufgelöst und in Klasse umgewandelt
- ...
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Es gibt für Git ein schönes Buch - da drin findest Du alles, was Du wissen willst
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert