so you make a branch for each feature, then when the feature is complete you squash and merge (or whatever) it into the develop branch, and then when all features are ready for a release it goes to master?
Caaaaarrrrlll29-May-18 12:25 AM
almost
you forgot about the release branch
When it is time to make a release, a release branch is created off of develop
(edited)
The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch.
(edited)
When the release is finished, the release branch is merged into master and into develop too,
Davnit29-May-18 12:26 AM
makes sense
Caaaaarrrrlll29-May-18 12:27 AM
"release" branch is more like a staging branch
there's a final step: when merging release->master, you tag it as well
hotfix branches are fun as well.
Davnit29-May-18 12:28 AM
i'm sure i'll get the hang of it after fucking it up a few times
Caaaaarrrrlll29-May-18 12:29 AM
not saying we have to follow it
but it's very clean
beats just committing to master all day then eventually tagging a release
Davnit29-May-18 12:29 AM
thats what we do with stealthbot lel
Caaaaarrrrlll29-May-18 12:29 AM
gitflow allows all of us to work in pieces then merge later
and test it before release
each piece is a feature branch, which are children of the develop branch
there's not supposed to be any conflict
if a feature needs another feature to work, then that feature should wait for the other feature to be merged to develop before continuing
when the other feature is merged, you can do a git pull on the feature branch to pull down updates from develop
there's countless articles on the web if you get lost at any point
it's the best practice for git projects that have simultaneous features being worked on
Davnit29-May-18 12:33 AM
sounds good to me
Caaaaarrrrlll29-May-18 12:43 AM
made develop and locked branches(edited)
Glyph29-May-18 12:47 AM
should i bother with a git GUI?
Davnit29-May-18 12:48 AM
i use the github desktop client mostly for diffs and making commits
Imagine that you want to develop a non-trivial end-user desktop (not web) application in Python. What is the best way to structure the project's folder hierarchy?
Desirable features are ease of
Doesn't too much matter. Whatever makes you happy will work. There aren't a lot of silly rules because Python projects can be simple.
Davnit29-May-18 01:10 AM
directory name is part of namespace so probably /bcb/
Caaaaarrrrlll29-May-18 01:10 AM
Since a top-level /src directory is seen by some as meaningless, your top-level directory can be the top-level architecture of your application.
Glyph29-May-18 01:11 AM
hmm
i just realized soemthinbg
are we making an actual chat bot for discord? if so we'll need to actually make a bot. without discords api i mean.
Caaaaarrrrlll29-May-18 01:12 AM
it's not for discord
Davnit29-May-18 01:12 AM
no we are not doing anything related to discord
Caaaaarrrrlll29-May-18 01:12 AM
it's for battlenet v1
Glyph29-May-18 01:12 AM
i thought it was for bnet/discord
oh
Caaaaarrrrlll29-May-18 01:12 AM
we could have a discord module
like a plugin
Glyph29-May-18 01:12 AM
i see
okok
so were not using CAPI?
Caaaaarrrrlll29-May-18 01:13 AM
this is supposed to be a barebones bot that can simply have "modules" plugged into it
Davnit29-May-18 01:13 AM
the idea is to use CAPI
Caaaaarrrrlll29-May-18 01:13 AM
it's the scaffolding for other modules
Glyph29-May-18 01:13 AM
okay
Davnit29-May-18 01:14 AM
so we'd probably want /bcb/ and then also in the root a /plugins/ or /modules/
This client implements V1 of the CAPI spec, outlined in the Chat Bot API Alpha v1.pdf document. A sample implementation is included at the bottom of the capi.py file and can be run by calling that ...
I want to import foo-bar.py. This works:
foobar = import("foo-bar")
This does not:
from "foo-bar" import *
My question: Is there any way that I can use the above format i.e., from "foo-bar"
The official home of the Python Programming Language
Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
