I feel like this is a feature request/question for Github devs but since Github by default doesn't show you python 2 or 3 (but instead just python), how to easily tell other than cloning it or browsing in source code, assuming the Repo. document doesn't say (and often they just show pip without specifying whether it is pip2 or pip3. I know I can just do pip search as well as I prefer if I can just see it right in the browser.
Maybe there is a chrome plugin but my googfu has no luck finding it thus far.
It seems that you are asking for GitHub to tell you if a project or repository is Python 2.x or Python 3.x, and that is just not reasonably possible. If it is available through pip (pip2 or pip3) you can query that way (already mentioned), but it is worth explaining why GitHub cannot do what you ask :
Python packages, projects, and/or code are not Python 2.x or Python 3.x (exclusive or), rather, it is possible two write code that works with either.
GitHub could try to infer the prevailing version of Python within a repository, however, if they did so programmatically (even using sophisticated AI) it would be wrongs far too often.
GitHub could try to force users to pick one, which would alienate many, frustrate many more, and generally provide no significant benefit to the community.
Even if GitHub forced folks to choose, it is surprisingly common for authors to know know if their code will work fully in one version or the other.
Although you could envision GitHub trying to enforce designating repositories as "Python 2.x" or "Python 3.x", this makes little sense (see first bullet item) and would give the Python ethos community a severe allergic reaction since it's antithetical to the culture.
TL;DR: Github currently doesn't support distinguishing between Python 2 and 3 in the repository language statistics.
Assuming you're referring to the Github language statistics on the front page of a repository (see screenshot of example repo below with red box around programming language statistics):
This will not distinguish between Python 2 and Python 3 code. Apart from cross-compatability reasons, part of the reason why is that Python 2 and Python 3 code files sometimes share the same file extension names, and the Linguist library which is used to calculate these statistics does not differentiate between them.
You can see this section of the languages.yml file in the Linguist Github repo to see what's considered a Python file or not. Note that there's no distinction anywhere in the languages.yml between Python 2 and Python 3 code.
Related
We are working on a group project written in MatLab. We all need to be able to access and write the same program, sometime simultaneously. We are working on a scientific Linux distribution. We are all physicists so we would rather find a very simple - ideally GUI, solution.
It sounds like GitHub would enable us to write simultaneously and merge mismatched code but it seems so complicated. We don't really understand the push/pull/fork/commit terminology and we would rather not study it if there is an easier option.
What is the path of least resistance for a group project in Matlab?
I regularly use Subversion for group MATLAB projects. It has what I find a slightly simpler workflow than Git/GitHub.
The latest versions of MATLAB integrate directly with Subversion, so you can check things in and out directly from within the MATLAB workspace. Alternatively you can use TortoiseSVN, which integrates within Windows Explorer (I believe there is an equivalent for Linux as well).
However, I'll speak bluntly - Git and GitHub are really not that hard, and I'm pretty sure that anyone who's clever enough to be a physicist working with MATLAB is clever enough to understand them as well. Although Subversion is a bit simpler to learn, Git and GitHub have a lot of advantages, they integrate well with many other services, and they're just overall kind of better. The latest versions of MATLAB integrate directly with them in the same way as with Subversion.
Using Matlab for development and Mercurial for version-control, how do I properly version all code for each of my projects, when they share some common classes and functions?
My current scheme addresses this imperfectly; I have a repository for each project and a repository for the common library. This necessitates a manual manipulation protocol, including:
Manually referencing the project name/version in the commit description for the library
Manually updating the changeset for both the project and library, if reverting to a previous state
This has worked reasonably well so far, but does run the risk of human error in following the protocol and unintended consequences of a library modification on another project. The latter can be addressed with hg update -r on the library, but is error-prone since I have to remember to go back, as I move between projects.
Searching here (and elsewhere), I thought I had found salvation in sub-repository branches, only to discover the practice is basically frowned upon and considered a feature of last resort.
I then found that some folks eschew direct versioning with the project in favor of treating the library as a package for the build software to manage. Taking the library off the Matlab path, creating version clones and telling the builder which one to use, for any particular project, is a brilliant idea - except that I also use the Matlab interpreter to run/debug my code, as well as use the library in various scripts, so I need the library on the Matlab path - which means the builder will automatically pick up the library version that's on the path.
The only other scheme I can think of is to copy the library dependencies into the Project folder for revision control by the project repository. A change protocol would have to include copying the affected library class/function back to the library folder and typing an appropriate commit message. The trick here would be in manually updating project copies of library files, unless there's a Mercurial command to selectively pull from a foreign repo.
Does anybody have a better, more robust way to manage shared library code among projects in both interpreter and build environments?
Thanks to everyone who commented and to those who took the time to read my question. I am loathe to ask questions, since I never think my queries are so novel as to be previously un-asked. But in this case, I was finding it hard to come up with the right search terms/phrase; hence the less-than concise phrasing of my question.
I still don't know if there's a standard approach to managing software configuration for a project, when it includes non-project-specific dependencies, but the scheme I've decided to adopt is outlined below. I should say that the development framework I'm using is Matlab, which may well be argued isn't a terribly good framework for developing a GUI application, but it's the only one I have for now. Should I move to .Net, or some other framework, then maybe some of the issues I'm having would be much more readily resolved.
I decided the ability to version a project in its entirety took precedence and so I copied all of the project-agnostic dependencies (that is, functions and classes that I've developed) from a central library repo to a folder within the project repo.
It just means I have to be disciplined in managing the Matlab search path, as well as the protocol for copying changes made to these dependencies back to the central library - and for polling the library for any changes that originated from another project.
This doesn't seem elegant, but it does make me think more carefully about the functions and interfaces that I put into the library, which should be a good thing.
Myself, I'd be perfectly happy with Git or Mercurial, but I'm tying to identify a version control system which all our Windows admins could use for sharing script code, meeting the following requirements:
distributed, i.e. we want a central repository where users can clone or fork from
GUI on Windows (bonus points for Explorer integration like the TortoiseCVS forks)
Windows-friendly installation (e.g. msysgit's OpenSSH or PuTTY configuration disqualifies it)
easy to understand, i.e. the end users probably do not know or use terms like trunk, branch, and tag, and ideally would never need to
integrates with popular text/code editors like Notepad++ (this is not a must-have, but would be a real plus)
Maybe I'm asking too much, but there must be some usable VCS out there to fit the bill!
Some thinking
I can't see any strong reasons in your use-case for DVCS (i.e. reasons for cloning-merging instead of personal "shelves")
Friendly installation: for admins (even Windows-admins must have brain and easy understand "OpenSSH or PuTTY configuration")?
Ideas
You can see at Smart* products from Syntevo (Full-size GUI, not pure shell-extensions /but have shell-extension also/). Beware - Java! SmartGit have human-brain-friendly config, early versions also have support for Mercurial
For editors with SCM-integration I can suggest EditPlus (not free, but reasonable good price) - support from a box for basic Subversion commands (in a main menu), latest build have added support for TortoiseGit. But - with the help of UserTools virtually any (CLI?) command can be added to EditPlus interface and executed in EditPlus editor-window
I'm not aware of any non-IDE editors on windows other than maybe Emacs and UltraEdit that have version control support. Otherwise, Mercurial really does fill the bill. It's distributed, it has TortoiseHg, it has several options for windows installers (including admin and non-admin installs), and at least when using TortoiseHg, it's relatively easy to understand.
No VCS in the world is going to completely insulate users from its own concepts, but if you don't use branches and tags, the issue isn't going to come up (personally I'd recommend at least learning about tags -- they're easier to work with than raw rev spec hashes). Were you to find some other VCS that isn't one of these mainstream choices, I'd be interested in knowing about it, but chances are you'd also find it was one or more of a) expensive, b) has a vanishingly small community, and c) no sites like sourceforge, google code, or bitbucket to host your projects.
Now for one major alternative: If your users are primarily editing documents, then possibly you want a CMS of some sort, for which you have options ranging from the likes of Drupal, Joomla, and Magnolia, to something simpler like a Wiki. MediaWiki with some syntax hilighting plugins might be just the thing for single-file scripts. This is a centralized solution without any real editor integration however, so I'm not sure it's the workflow you're looking for. There are some wikis based on DVCS's (mostly git) but I find they tend to be the worst of both worlds.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
So I want to get a project on a distributed version control system, such as mercurial, git, or bazaar. The catch is that I need the Windows support to be good, i.e. no instructions that start off with "install cygwin...". Now I've heard that git's Windows support is decent these days, but don't have any first hand experience. Also, it sounds like the bazaar team has an explicit goal of making it as multiplatform as possible.
Can I get any recommendations?
I use msys-git on windows every single day. Works fast and flawlessly.
Although the newer build has some problems with git-svn, this build (Git-1.5.5-preview20080413.exe) has a working git-svn.
There's a nice comparison between git, hg and bzr in this InfoQ article. They all have their strengths and weaknesses. You'll have to think about your project and your workflows and choose the best fit. The good news is that they're all fairly good.
At last I checked, the only thing you need for Mercurial is Python and to grab a binary package. If you find yourself with more time and want to fiddle / build it yourself, look here.
The only real drawback with HG is its idea of branching .. but for some people that's a major plus.
I like it because its intuitive, easy to install and works on anything that Python does. I don't think that all of the available plugins will work for you, but most should.
I've had the best luck with Bazaar, followed by Mercurial. Never could get Git to work correctly. A quick search shows that Git still requires clunky emulation layers like Cygwin/MSYS, and I can't find any integration tools like TortoiseBzr for Git.
With Mercurial in Windows, I had several minor issues (insensitive paths, symlinks, ). They were usually fixed eventually, but I felt that the same quality of testing was not applied to running on Windows as for the other platforms. Bazaar also had better documentation for integrating with native applications like Visual C.
EDIT: Perhaps add a "dvcs", "distrubutedversioncontrol", "distrubuted"
I've used Mercurial on Windows with no problems. You can use TortoiseHG or just use the command line. Mercurial does require Python, but that is easy to install in Windows as well.
Mercurial Binary Packages
I agree with basszero. I'm using mercurial under windows and it's as easy and reliable as it can get. My development team is spread over Europe (well Dublin and Vienna :-).
We use VPN to commit or sometime the built in webserver (hgserve). Both work fine with no problems out of the box.
Also diff3 open source tool works perfect with mercurial and TortoiseHG out of the box.
If you are concerned about an easy to use interface:
The bazaar folk now include TortoiseBzr in their windows binary package. That's got to be a pretty strong indicator that they think it is up to snuff. I don't know what the maturity/stability of TortoiseHg is, but there certainly isn't a decent GUI interface for git yet, and the MSYS git build still needs some work IMO.
If your team are comfortable with or prefer the command line, then either bazaar or mercurial would probably work well for you, and are both probably about the same in terms of learning curve. Git's learning curve is much higher. It is like the swiss-army knife that is almost wider than it is long, with all the little gadgets and do-dads in it and hanging off it, with the springs so tight that you occasionally slice a finger open trying to prise a blade out.
In my experience using GIT on windows is a major pain. But I have been using Fossil SCM for some time now, and I think it actually fits your needs exactly.
It also has a built in Ticket system and a Wiki. And the whole program is contained in 1 file and it works right out of the box.
I totally recommend it.
Here is a link to the site http://www.fossil-scm.org/
Remember, this site is self hosting, what that means is you are looking at the web interface to fossil it self, when you look at tickets and the wiki and documentation, you actually are using fossil.
But if your project has millions of lines of code and is a few gigabytes in size, you have to use GIT, there is no way around that problem.
Enjoy.