Forums

Hi,

Is there a way for a team of 3 to 5 developers to share the same account but have different login ids?

Not right now, though it's something we've considered -- we haven't worked out what such a thing would look like, though. Would this be for multiple people maintaining the same website? Or something else? If you let us know more about what you'd use it for, it would really help us make sure we're building the right thing :-)

Sounds like maybe gdover is hoping for one paid account worth of quota shared among 3-5 users.

I'm evaluating PythonAnywhere right now, but if it works well I plan to encourage some colleagues to join as free, and use a private bitbucket repository to coordinate work. I'd always want a private workspace to work in -- I don't want them accidentally (or intentionally) mucking up my work.

Suggestion: in the web server tab, being able to add SQL databases, Mercurial servers. It might also be nice to have an "easy mode" for securing access -- private web servers would operate just like the normal ones, only they'd have an access control list and refuse connections that didn't originate from the PA users listed on the ACL. Another tab could list all web servers that you've been invited / accepted access to, including the private URL you can use for access.

Interesting ideas! It would be an intriguing engineering challenge to put something that checked ACLs in the request-response stack without making everything horrendously slow. But it would probably be doable. What would be the use case? Is this so you can have a staging / development site that is only accessible to the developers and designers?

I have a team of 5 developers. We all work on the same code base from time to time. Right now we each have VS 2012 and check-in our code to Team Foundation Server (TFS) so that others can check out and continue development.

However, as I evaluate PA for a new project, I'd like to have one account that up to five developers can share. They would each have separate login and workspace. We would then push code to production workspace after testing. It should work like Google Apps for Business (Google Docs).

If for some reason a developer leaves, we would move his/her files to others and prepare the account for the new developer. Also, we could monitor developer productivity better with a multi-user account.

Just to clarify, you're suggesting each developer is an independent user with their own file storage, but that there's also a special "team" user with its own storage where you can put a git repository or similar? Or are you suggesting each user shares the same home directory? It's not quite clear to me whether by "workspace" you mean file storage, running shells and processes, or both.

I could definitely see mileage in a new "organisation" account type with its own storage, web apps and scheduled tasks, which individual user accounts could then be given access in addition to their own space. Perhaps for convenience developer home directories could be made available in the shared space too, but perhaps that's not useful. Developer accounts being deleted could be handled by copying their files to the shared account and leaving the account owners to delete them if not required.

One way you could do what you want now is to have separate normal PythonAnywhere accounts, one for each developer and one for the team as a whole. The team account could run the production service, and also would contain a git repository that your developers could then clone into their own accounts. They could work on new features in their own accounts, and then push them to the team one when they were complete. What do you think?

Interesting. I'll put this in action and see how it works for us.

Thanks,

Is this the way to go if I lack technical skills but hired someone with technical skills to write some python and deploy it for me?

To avoid having to give them my username and password for my account, I would have to buy a second account, have them deploy things to that account using the password and username of that account, and then, after testing in that account, transfer the working thing to my account, then close the other account?

I lack the skills to write it in the first place and I also lack the skills to transfer it to my account and get it to work after the transfer, so I'll still have to give someone with technical skills access to my account.

Is there a way to give the technical person limited access to my account so they don't have my password yet so they can deploy what they wrote and test it but not do other things in my account such as see my billing information?

In my particular case i think the technical person will be using virtualenv because they wrote some code in newer versions of django and matplotlib than are listed in your batteries descriptions.

Sure- in that case you could set that person as your teacher, and they would be able to read/write/execute all files on your account, help your setup your webapp etc, but will not have access to your billing information. You can also un-set them as your teacher any time you want.

Sorry for adding to an old thread but this is the very first place google points you to when asking about this so it seems like a good place to confirm if a team workflow is available or not without giving full access to your account.

So if you go the teacher/student sharing method, the teacher will have full access to the files in the student's accounts, and will be able to edit it, as well as say setup tasks/webapps etc. But they will not have access to the account information.

This might work either by making several accounts or allowing access to all the work either by myself or my other developers. Both seem far from practical in many typical development scenarios.

This seems like something overlooked, now for years, and wish it had a workflow more like github.

wait- just to clarify, you can use github on pythonanywhere

I understand, I just wish that myself and the developers had the same access level on a single app without workarounds. I realize they can work in other environment and we can use github to deploy but I feel it would be simpler to share apps like projects in other software tools.

Overall pythonanywhere has value but I was hoping for a little bit more on a collaborative project.

I will let this go for now. Thanks for the help and suggestions!

I saw there are some new sharing features with consoles, is similar features coming for the apps?

I'm afraid we have no immediate plans to improve features for team collaboration, no.

Hello,

I have uploaded video on my pythonanywhere server, it's working perfect on mozila and chrome but not working on safari.

Can help me figure out this issue?

Thanks, Avinash.

I think you've sent us an email about this too, so let's keep the discussion there -- if there's anything broadly useful for PythonAnywhere users, we can post back here.

This would be a good feature to have. Since Pythonanywhere is providing the development environment it would be nice if it had git self hosted (rather than just using github) where you could setup multiple users on a single account. Paid account of course :-), because you all have to eat.

Thanks! I've upvoted that too :-)

Has there been any movement on this over the years?

I would like to keep my main admin account and give other team members limited access to some features such as SSH and Database but not allow them into the main UI, etc.

No, there has not been any movement on it. I have upvoted the ticket for you.

Hello, is there any movement on the sharing topic? As a teacher, I would like to create a PostgreSQL database on my paid account and allow my students to access it. The student could have separate free accounts. It would be sufficient if they could access the database through an SSH tunnel and pgAdmin. Thanks in advance.

If you create a Postgres database, then students would be able to access it from within PythonAnywhere if they had the correct credentials to connect to it. Unfortunately to be able to use SSH tunnels and pgAdmin, they'd need to have paid accounts, as both use SSH and that's a paid-only feature.