{
    "info": {
        "author": "Van Long LE",
        "author_email": "vanlong.le@cenaero.be",
        "bugtrack_url": null,
        "classifiers": [
            "License :: OSI Approved :: MIT License",
            "Programming Language :: Python",
            "Programming Language :: Python :: 3",
            "Programming Language :: Python :: 3.6",
            "Programming Language :: Python :: Implementation :: CPython",
            "Programming Language :: Python :: Implementation :: PyPy"
        ],
        "description": "\ufeff# pepsepy Module Repository\n\n## Table of Contents\n\n- [pepsepy Module Repository](#pepsepy-module-repository)\n  - [Table of Contents](#table-of-contents)\n  - [GIT](#git)\n  - [Create master branch and push it to server](#create-master-branch-and-push-it-to-server)\n  - [Collaborating](#collaborating)\n    - [Create a new branch](#create-a-new-branch)\n    - [Git Branching - Rebasing](#git-branching---rebasing)\n      - [Basic Branching and Merging](#basic-branching-and-merging)\n        - [Simple workflow](#simple-workflow)\n        - [Basic merge conflicts](#basic-merge-conflicts)\n      - [Basic rebasing](#basic-rebasing)\n  - [Structure of the Repository](#structure-of-the-repository)\n  - [Install](#install)\n  - [Install using pip](#install-using-pip)\n  - [Uninstall](#uninstall)\n  - [To-do](#to-do)\n  - [GitLab CI/CD: GitLab Continuous Integration](#gitlab-cicd-gitlab-continuous-integration)\n    - [Continuous Integration](#continuous-integration)\n    - [Continuous Delivery](#continuous-delivery)\n    - [Continuous Deployment](#continuous-deployment)\n    - [How GitLab CI/CD (or travis CI) works](#how-gitlab-cicd-or-travis-ci-works)\n      - [Git - taging](#git---taging)\n\nThis simple project is an example repo for Python projects.\n\nLearn more <http://www.kennethreitz.org/essays/repository-structure-and-python>\n\ngit clone https://gitlab.com/vlle-cenaero/pepsepy.git\n\ncd pepsepy\n\npython setup.py install [--record files.txt]\n\n## GIT\n\nCommand line instructions\n\nGit global setup\ngit config --global user.name \"Van Long L\u00ea\"\ngit config --global user.email \"vanlong.le@cenaero.be\"\n\nCreate a new repository\ngit clone https://gitlab.com/vlle-cenaero/pepsepy.git\ncd pepsepy\ntouch README.md\ngit add README.md\ngit commit -m \"add README\"\ngit push -u origin master\n\nExisting folder\ncd existing_folder\ngit init\ngit remote add origin https://gitlab.com/vlle-cenaero/pepsepy.git\ngit add .\ngit commit -m \"Initial commit\"\ngit push -u origin master\n\nExisting Git repository\ncd existing_repo\ngit remote rename origin old-origin\ngit remote add origin https://gitlab.com/vlle-cenaero/pepsepy.git\ngit push -u origin --all\ngit push -u origin --tags\n\n## Create master branch and push it to server\n\ngit init\n\ngit remote add origin http://gitlab.com/vlle-cenaero/pepsepy.git\n\nMake changes ...\n\ngit add files folders\n\ngit commit -m \"messages\"\n\ngit push origin master\n\n## Collaborating\n\n### Create a new branch\n\ngit checkout -b pepseday2019\n\nadd and commit\n\ngit push -u origin new_branch: push to server\n\ninvite new collaborators\n\nFor new collaborators:\n\ngit clone http://gitlab.com/vlle-cenaero/pepsepy.git\n\ngit checkout --track origin/pepseday2019\n\nmake changes\n\ngit add . && git commit\n\ngit fetch or git pull\n\nsolve conflicts\n\ngit push -u origin pepseday2019\n\nThe conflicts comme here\n\ngit push -u [--set-upstream] origin pepseday2019\n\nThe next step is to see how to merge pepseday2019 to master\n\nCase: work on pepseday2019, the work is done and readay to merge it backt to master\n\n(--rebase will get the changes from master and could overwrite changes other people made)\n\nThe goal is to keep pepseday2019 branch updated with the things happening in master and later could merge them back into master\nNo, rebase never overwrite, it just trying to achieve a cleaner history, by reattach (or fake) the history to the late point of the master. (it undoes the commits from the branch pepseday2019, then applies the commit backt to )\n\n### Git Branching - Rebasing\n\nIn Git, there are two main ways to integrate changes from one branch into another: the **merge** and the **rebase**.\n\nThe easiest way to integrate the branches, as we\u2019ve already covered, is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).\n\n![altext](https://git-scm.com/book/en/v2/images/basic-rebase-2.png)\n\n#### Basic Branching and Merging\n\n##### Simple workflow\n\n1. Do some work on a website (git add, git commit)\n2. Create a branch for a new user story you're working on (git checkout -b new_branch)\n3. Do some work in that branch (git commit -a -m 'added a new footer [issue 53]')\n\nAt this stage, you\u2019ll receive a call that another issue is critical and you need a hotfix. You\u2019ll do the following:\n\nNote: when you\u2019ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don\u2019t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the `git stash` command.\n\n```Git\ngit status\n\nChanges to be commited\n...\n\ngit stash\nSaved working directory and index state\n...\n\ngit status\n# On branch master\nnothing to commit, working directory clean\n```\n\nAt this point, you can switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you\u2019ve stored, you can use git stash list:\n\n`git stash list`\n\n`git stash apply` (most recent) or `git stash apply stash@{2}` (specific stash)\n\n1. Switch to your production (git checkout master)\n2. Create a branch to add hotfix (git checkout -b hotfix)\n3. After it is tested, merge the hotfix branch, and push to production (git commit -a -m 'fixed the broken email address')\n4. Switch back to your original user story and continue working (git checkout master, git merge hotfix)\n\nAfter your super-important fix is deployed, you\u2019re ready to switch back to the work you were doing before you were interrupted. However, first you\u2019ll delete the hotfix branch, because you no longer need it\u2009\u2014\u2009the master branch points at the same place. You can delete it with the -d option to git branch:\n\ngit branch -d hotfix\n\nNow you can switch back to your work-in-progress branch on issue #53 and continue working on it.\n\n```Git\ngit checkout iss53\nvim index.html\ngit commit -a -m 'finished the new footer [issue 53]'\n```\n\nIt is worth noting here that the work you did on your hotfix branch is not contained in the files in your iss53 branch. If you need to pull it in, you can merge your master branch into your iss53 branch by running `git merge master`, or you can wait to integrate those changes untill you decide to pull the iss53 branch back into master later\n\nThe issue #53 is commplete and ready to be merged into your master branch.\n\n```Git\ngit checkout master\ngit merge iss53\n```\n\n##### Basic merge conflicts\n\nFor resolving the merge conflict, you can run git mergetool, which files up an appropriate visual merge tool and walks you through the conflicts\n\n#### Basic rebasing\n\nThere is another way to integrate the branches: you can take the patch of the change that was introduced\n\n---------------\n\nIf you want to learn more about `setup.py` files, check out `this repository <https://github.com/kennethreitz/setup.py>`_.\n\n## Structure of the Repository\n\n- README.md\n- LICENSE\n- setup.py\n- requirements.txt\n- pepsepy/__init__.py\n- pepsepy/core.py\n- pepsepy/util.py\n- docs/conf.py\n- docs/index.md\n\n## Install\n\npython setup.py install\nor\npython setup.py install --record files.txt : To record a list of installed files\n\n## Install using pip\n\n## Uninstall\n\nLinux: xargs rm -rf < files.txt or cat files.txt | xargs rm -rf\nWindows: using Powershell\nGet-Content files.txt | ForEach-Object {Remove-Item $_ -Recurse -Force}\nThen delete also the containing directory: ~/Programs/anaconda/.../pepsepy\n\n## To-do\n\n- merge pepseday2019 to master\n- create release entries\n- create changelog\n- create wiki\n- create CONTRIBUTING.md\n- create gitlab CI/CD\n  \n## GitLab CI/CD: GitLab Continuous Integration\n\nThe continuous methodologies of software development are based on automating the execution of scripts to\nminimize the chance of introducing errors while developing applications. They require less human\nintervention or event no intervention at all, from the develoment of new code until its deployment.\n\nIt involves continuously building, testing, and deploying code changes at every small iteration, reducing\nthe chance of developing new code cased on bugged or failed previous versions\n\n### Continuous Integration\n\nDevelopers push code changes every day, multiple times a day. For every push to the repository, you can create a set of scripts to build and test your application automatically, decreasing the chance of introducing errors to your app.\n\nThis practice is known as Continuous Integration; for every change submitted to an application - even to development branches - it\u2019s built and tested automatically and continuously, ensuring the introduced changes pass all tests, guidelines, and code compliance standards you established for your app.\n\n### Continuous Delivery\n\n Continuous Delivery is a step beyond Continuous Integration. Your application is not only built and tested at every code change pushed to the codebase, but, as an additional step, it\u2019s also deployed continuously, though the deployments are triggered manually.\n\nThis method ensures the code is checked automatically but requires human intervention to manually and strategically trigger the deployment of the changes.\n\n### Continuous Deployment\n\n Continuous Deployment is also a further step beyond Continuous Integration, similar to Continuous Delivery. The difference is that instead of deploying your application manually, you set it to be deployed automatically. It does not require human intervention at all to have your application deployed.\n\n- GitLab's built-in tool for sofware development using continuous methodology\n  - Continuous integration (CI)\n  - Continuous delivery and deployment (CD)\n\n![altext](https://docs.gitlab.com/ee/img/devops-stages.png)\n\n### How GitLab CI/CD (or travis CI) works\n\n To use GitLab CI/CD, all you need is an application codebase hosted in a Git repository, and for your build, test, and deployment scripts to be specified in a file called .gitlab-ci.yml, located in the root path of your repository.\n\nIn this file, you can define the scripts you want to run, define include and cache dependencies, choose commands you want\nto run in sequence and those you want to run in parallel, define where you want to deploy your app, and specify whether\nyou will want to run the scripts automatically or trigger any of them manually. Once you\u2019re familiar with GitLab CI/CD you\ncan add more advanced steps into the configuration file.\n\nTo add scripts to that file, you\u2019ll need to organize them in a sequence that suits your application and are in accordance with the tests you wish to perform. To visualize the process, imagine that all the scripts you add to the configuration file are the same as the commands you run on a terminal in your computer.\n\nOnce you\u2019ve added your .gitlab-ci.yml configuration file to your repository, GitLab will detect it and run your scripts with the tool called GitLab Runner, which works similarly to your terminal.\n\nThe scripts are grouped into jobs, and together they compose a pipeline. A minimalist example of .gitlab-ci.yml file could contain:\n\nbefore_script:\n\n    - apt-get install rubygems ruby-dev -y\n\nrun-test:\n\n    script:\n\n        - ruby --version\n\nThe before_script attribute would install the dependencies for your app before running anything, and a job called run-test would print the Ruby version of the current system. Both of them compose a pipeline triggered at every push to any branch of the repository.\n\nGitLab CI/CD not only executes the jobs you\u2019ve set, but also shows you what\u2019s happening during execution, as you would see in your terminal:\n\n![altext](https://docs.gitlab.com/ee/ci/introduction/img/job_running.png)\n\n![altext](https://docs.gitlab.com/ee/ci/introduction/img/gitlab_workflow_example_11_9.png)\n\nsource: https://docs.gitlab.com/ee/ci/introduction/index.html\n\n#### Git - taging\n\ndelete local tag '12345'\n\n`git tag -d 12345`\n\ndelete remote tag '12345' (eg, GitHub version too)\n\n`git push origin :refs/tags/12345`\n\nalternative approach\n\n`git push --delete origin tagName`\n\n`git tag -d tagName`",
        "description_content_type": "text/markdown",
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://gitlab.com/vlle-cenaero/pepsepy",
        "keywords": "",
        "license": "MIT",
        "maintainer": "",
        "maintainer_email": "",
        "name": "pepsepy",
        "package_url": "https://pypi.org/project/pepsepy/",
        "platform": "",
        "project_url": "https://pypi.org/project/pepsepy/",
        "project_urls": {
            "Homepage": "https://gitlab.com/vlle-cenaero/pepsepy"
        },
        "release_url": "https://pypi.org/project/pepsepy/0.0.1/",
        "requires_dist": null,
        "requires_python": ">=3.6.0",
        "summary": "python package for PEPSE project",
        "version": "0.0.1"
    },
    "last_serial": 5149817,
    "releases": {
        "0.0.1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "9671d067f5a0da2b6df74deea8d888b2",
                    "sha256": "5decf54264d90f9b3532cd69baa129ccbca93c6ba67561378a9b518e77c4192b"
                },
                "downloads": -1,
                "filename": "pepsepy-0.0.1.tar.gz",
                "has_sig": false,
                "md5_digest": "9671d067f5a0da2b6df74deea8d888b2",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": ">=3.6.0",
                "size": 12985,
                "upload_time": "2019-04-16T12:28:25",
                "url": "https://files.pythonhosted.org/packages/e4/a3/b4da80071487c7f56ab9b05923a25df76b80bebcfa973f5fd93d3a37934f/pepsepy-0.0.1.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "9671d067f5a0da2b6df74deea8d888b2",
                "sha256": "5decf54264d90f9b3532cd69baa129ccbca93c6ba67561378a9b518e77c4192b"
            },
            "downloads": -1,
            "filename": "pepsepy-0.0.1.tar.gz",
            "has_sig": false,
            "md5_digest": "9671d067f5a0da2b6df74deea8d888b2",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": ">=3.6.0",
            "size": 12985,
            "upload_time": "2019-04-16T12:28:25",
            "url": "https://files.pythonhosted.org/packages/e4/a3/b4da80071487c7f56ab9b05923a25df76b80bebcfa973f5fd93d3a37934f/pepsepy-0.0.1.tar.gz"
        }
    ]
}