In case you didn't understand:

The first option means you want UserLixo to deploy the source right after .upgrade. i.e. .upgrade will take 4 minutes to finish.

The second option means you want UserLixo to .upgrade normally (in a few seconds) and to deploy you'd use a second command, something like .rebuild or .deploy (the command of the first poll)

If we choose the second option, i think the name .deploy makes more sense because it will be divided in steps: .upgrade then .deploy

.rebuild needs some explanation to understand what is it for, but you can guess what .deploy does by its name

- What is .deploy used for?
You may know that Heroku doesn't have a persistent storage, it will periodically reset your workdir to the lastest deploy. Well, it affects UserLixo because you would lose any files that you might have saved after the deploy (yes, it would delete plugins)

To avoid this, i made the script self-deploy on .upgrade. In other words, it will upgrade the source and send/deploy the new files via git. So you don't go back to an old version after a restart.
Also with self-deploy you keep the new files (plugins) safe (they won't be deleted by heroku).

⚠️ Heroku users, execute the command below, changing "userlixo" to the value you want to set as custom hostname (that will be shown on .info, neofetch...):

ex config_vars = app.config()
config_vars['FAKE_HOSTNAME'] = 'userlixo'

After this, your app will be restarted.
It's needed for the next UserLixo release ;)

To fake the username in Heroku, run the command below replacing "personal" with the new username:

ex config_vars = app.config()
config_vars['USER'] = 'personal'

You don't need to deploy. The command above will restart your app and you'll be ready to see the new username in neofetch :)

To see the original hostname: sh cat /etc/hosts
To see the original username: sh whoami

❕ Feature discussion

To login at Heroku, you need to clone the repo locally, create and activate a virtualenv and install the requirements, run 'python -m userlixo.login', login and then copy two variables that it will print: PYROGRAM_CONFIG and PYROGRAM_SESSION.
Sounds complex and boring, right?

Since the first versions i was thinking about how can i improve this step and the best i could think is to run a web interface in the same Heroku app, but i don't know if it's possible in the free plan. Anyway i'm not good at web development so it would take more time than usual.

Today i tried to think another solution and i reminded a bot named Pyrogram Session Bot which you can use to login in your account and get the .session file.
I can use the same idea to let you login without installations in command line, 100% via Telegram

BUT, which bot i'd use? I could create an official bot to serve all users or i could add this feature to all userlixo assistant bots (with an option to disable).
If i add the feature to all assistants, the new users would have a lot of available bots to use when the official one is offline.
The problem is: anyone hosting UserLixo can alter the code to save your login, so who could the new user put trust in? Only in people that they know, but as far as the community grow up, we'll met new people that doesn't know anyone from us...

Either if i create or not, i will create the web interface in the future if possible

🔨 1 new commits to AmanoTeam/UserLixo:userlixo-czp

8595d0b: Increase max_length of database.Message.text to 4096 by Cezar H

This was making the bot not respond to some plugins because the characters limit for the inline message was 255.

If you are already running Userlixo, you need to update the table manually, just follow the steps below:

- For Heroku:
.ev from tortoise import Tortoise
conn = Tortoise.get_connection('bot_db')
await conn.execute_query('ALTER TABLE message ALTER COLUMN text TYPE VARCHAR (4096)')

It should return (0, [])

- For sqlite
.ev from tortoise import Tortoise
conn = Tortoise.get_connection('bot_db')
await conn.execute_query('DROP TABLE message')

then .upgrade

other? please comment

Thanks